Road to Microservices: Motivação

Artigo escrito em parceria com Felipe Coelho Machado

Estamos iniciando hoje uma série de artigos que têm como objetivo compartilhar a jornada de adoção de uma arquitetura de microsserviços, distribuída e orientada a eventos aqui na Warren. Vamos falar dos desafios e oportunidades que nos motivaram a tomar a decisão de seguir nesse caminho, movimentos que precisaram ser realizados, adaptação dos times e cultura, desenvolvimento de novas habilidades, necessidades de evolução de infraestrutura, observabilidade, segurança e um mundo de perguntas a serem respondidas.

Para isso, precisamos voltar lá para o começo de tudo. Vamos falar sobre a história da arquitetura da plataforma, o crescimento acelerado, tanto em tamanho de empresa como nos sistemas, além das perspectivas de futuro da companhia. Senta que lá vem história!

Como tudo começou

A Warren iniciou suas operações em 2016, com a ideia de transformar e simplificar a forma como se investe no Brasil. Por volta de 2017, tivemos o lançamento da primeira versão da plataforma. De lá pra cá, já passamos por 3 rodadas de investimentos, dobramos de tamanho várias e várias vezes e escrevemos milhares de linhas de código.

A concepção da plataforma se deu com uma escolha arquitetural (figura 1), pela qual os clients (mobile e web) se comunicavam com uma tier de APIs públicas, que faziam parte de um monolito desenvolvido em Node.js e que realizava a interface com o core financeiro da plataforma, outro monolito, esse desenvolvido em .NET.

Figura 1: Representação da Arquitetura

Essa composição foi construída através de cinco grandes codebases:

• 1 para cada mobile nativo;
• 1 Web;
• 1 em Node.js (para as APIs públicas); e
• 1 em .NET (core financeiro).

Todas eram mantidas por um time de engenharia pequeno e com o conhecimento de toda a plataforma. Com o conhecimento distribuído e um time enxuto, a plataforma evoluiu rapidamente. Outro ponto que nos ajudou bastante foi termos seguido uma estratégia cloud-first, o que nos permitiu focar no nosso produto. Conforme fomos crescendo, novos domínios foram adicionados e alguns desafios começaram a surgir, principalmente no que diz respeito à escala dos times e modularidade da plataforma.

Crescimento

Por volta de 2020, no começo da pandemia e com toda uma adaptação para o trabalho remoto, os desafios de tecnologia haviam mudado de tamanho e forma. Novos produtos surgiram e estávamos constantemente revisitando sistemas já existentes para garantir escala e estabilidade. Foi por volta deste momento que começamos a nos sentir um pouco limitados devido a arquitetura.

Implementações novas dentro do monolito traziam consigo algumas dores, apesar de permitirem lançamentos de novas funcionalidades em um espaço de tempo menor. O acoplamento estava subindo, e logo nos demos conta de que o monolito estava mais atrapalhando do que ajudando. Nossos processos de CI/CD haviam se tornado mais complexos, e alguns bugs inesperados surgiram, provocados pela dificuldade de reconhecer onde começava e terminava cada domínio. Algumas codebases separadas já haviam surgido, mas ainda de forma isolada e sem uma direção arquitetônica geral.

Era hora de esboçar o futuro da plataforma e exercitar como faríamos para continuar conquistando o Brasil.

A principal direção que decidimos seguir foi adotarmos sistemas assíncronos e reativos (sobre os quais teremos um artigo exclusivo no futuro). Isso não foi uma decisão repentina, mas sim por meio de muito estudo e contando com a ajuda de uma excelente equipe. Sabíamos que as mudanças dali pra frente deveriam ser feitas com cautela e em pequenos passos, experimentando e validando os tradeoffs.

Squads autônomas

É difícil falarmos de arquitetura sem citar a estratégia de tecnologia, mas imagine pular de 3 squads para cerca de 15 em um espaço de 1 ano. Agora imagine todos trabalhando nas mesmas codebases. Este é um exemplo de oportunidade quando você trabalha em uma empresa de crescimento acelerado, e o nosso trabalho é permitir que tecnologia e negócio cresçam juntos, garantindo que a tecnologia não será um limitador. Mas manter este equilíbrio é desafiador.

Juntamente com o crescimento dos times de engenharia, se mostrou necessária uma maior autonomia para que as tribos/squads pudessem evoluir o produto no que diz respeito a seus subdomínios, com maior independência e menos efeitos colaterais. Com o aumento gradual do acoplamento do monolito, havia ficado frequente que uma funcionalidade de uma squad impactasse de forma indesejada o comportamento de outra funcionalidade, afetando negativamente a velocidade e qualidade das entregas.

Foi nesse momento que começamos a desenhar o estrangulamento do monolito, definindo os limites de cada serviço de acordo com os subdomínios do negócio. O objetivo toda vez que propomos um desenvolvimento é atender a premissa de que os módulos sejam autocontidos e exponham na forma de eventos as informações importantes que outros subdomínios/módulos irão consumir.

Além da autonomia, esperávamos que, com subdomínios/módulos menores e com limites mais bem definidos, os times consequentemente seriam capazes de isolar suas funcionalidades e teriam maior profundidade nos escopos pelos quais são responsáveis. Mas os desafios estavam apenas começando.

“Novos problemas”

Ao mesmo tempo que uma abordagem distribuída e orientada a eventos nos trouxe uma série de benefícios, novos desafios se apresentaram também. Não queremos repetir dezenas de artigos e guias que se encontram na internet, mas podemos dizer com propriedade que alguns dos desafios vão muito além das habilidades técnicas.

Todos já devem ter lido algo sobre a complexidade operacional que é adicionada em arquiteturas distribuídas, e podemos dizer que neste quesito nos preparamos formidavelmente bem. Entretanto, poucos imaginam o quão complexo pode ser compreender e delimitar bem onde começa e termina cada domínio. Lá em 2017, você poderia escolher entre alguns fundos próprios da Warren e, 4 anos depois, estávamos oferecendo muito além disso, incluindo produtos de renda fixa, ações, previdência privada entre outros. Dá para imaginar quantos domínios novos surgiram neste período?

Muitas outras abordagens e técnicas entraram no nosso radar também. Passamos a estudar e aplicar padrões como: rastreamento distribuído, mensageria, idempotência, resiliência e tolerância a falhas. Algumas frentes ganharam ainda mais força, como infraestrutura como código, segurança, práticas de integração e entrega contínua, e a cultura DevOps como um todo.

E agora?

Nossa jornada na adoção de microsserviços ainda não chegou ao fim. Pelo contrário, enquanto escrevíamos este artigo, dezenas de pessoas continuavam e continuam escrevendo novos capítulos da nossa história. Muito aprendemos e muito evoluímos. Apesar de estarmos longe do fim, decidimos que havia chegado a hora de compartilhar um pouco com a comunidade e resolvemos começar contando um pouco da motivação por trás.

Sobre os desafios, é importante salientar que o tamanho deles é equivalente a recompensa. Esta é a natureza de empresas de crescimento acelerado.

Para concluirmos, teremos ainda pela frente uma série de artigos futuros relacionados, onde traremos estratégias de transição de arquitetura, lições aprendidas, observabilidade, mensageria, e quem sabe alguns atalhos que poderão ajudar muitos outros em suas jornadas.

Até a próxima!

Acompanhe nossas novidades em https://warren.com.br