BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Mudando de uma Arquitetura Monolítica para de Microserviços na SoundCloud

Mudando de uma Arquitetura Monolítica para de Microserviços na SoundCloud

Favoritos

Mudar a arquitetura da SoundCloud para Micro Serviços foi fundamental ao permitir que nossas equipes entreguem novas funcionalidades de forma mais rápida, Philip Calçado compartilhou em uma série de 3 artigos suas experiências quando saíram de uma arquitetura de sistema monolítico para micro serviços

A SoundCloud, uma plataforma de distribuição de áudio online que tem o brasileiro Philip Calçado como diretor de engenharia, foi originalmente criada como uma simples aplicação Ruby on Rails. Com o passar do tempo corrigir o sistema ao invés de resolver os problemas de escalabilidade tornou necessário que eles precisassem decidir em mudar tudo para uma arquitetura de micro serviços. Devido as experiências ruins que a equipe enfrentou depois de uma refatoração de grande proporção, decidiram investir em uma abordagem de não adicionar nada novo no antigo sistema e construir novas funcionalidades utilizando micro serviços.

Um problema que emergiu no inicio foi de que devido a grande parte da lógica ainda estar no sistema antigo muitos dos novos serviços ainda precisavam se comunicar com este antigo sistema. Uma solução que adotaram foi a de fazer uso de APIs públicas em conjunto com as novas APIs internas o que lhes ajudou a manter todos os novos micro serviços desacoplados do antigo sistema.

Depois que a mudança arquitetural foi implementada, o próximo desafio foi extrair funcionalidades do antigo sistema. O conceito de contexto delimitado vindo do Domain-Driven Design (DDD) foi escolhido para definir conjuntos de funcionalidades auto-contidas evitando ao máximo grandes refatorações necessárias para cada conjunto de funcionalidades extraídas, os novos micro serviços precisavam trabalhar com o antigo sistema pelo tempo que for necessário até que toda a lógica seja completamente modificada para a nova arquitetura. Durante a transição, a nova implementação do serviço acessava temporariamente a antiga base de dados como um serviço de consulta e apenas com permissão de leitura até que o novo serviço estivesse totalmente funcional. Aplicando estes princípios as equipes se habilitaram para extrair novas funcionalidades a serem construídas a partir do antigo sistema migrando tudo para micro serviços.

Com base em suas próprias preferências, a equipe decidiu escolher a plataforma JVM e suas diferentes implementações disponíveis. Ao buscar por frameworks que atendessem suas necessidades para RPC, resiliência e concorrência e estabeleceram que usariam o Finagle, um tipo de protocolo agnóstico para sistemas RPC, após investir tempo para resolver alguns problemas.

Mais uma vez, baseado em suas experiências anteriores, Philip resume este artigo afirmando que a nova arquitetura de micro serviços mostrou-se crucial para o desenvolvimento de recursos prontos para produção com ciclos de feedback mais curtos.

A ambição de Philip é completar sua série descrevendo como eles estão usando Finagle e Scala para mudar de uma API RESTful única para back-ends otimizados.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT