Evoluindo microserviços para monolito modular: desafios e lições

Quando iniciamos o desenvolvimento dos primeiros projetos na Wiipo, toda arquitetura foi desenhada baseada em microserviços e serverless. Além disso, os microserviços foram pensados para separar domínios de projeto, fluxo de deploy e componentes independentes.

Essa organização em microserviços ficou ótima no papel, mas na prática começamos a enfrentar algumas dificuldades. Em 4 anos de desenvolvimento, acumulamos mais de 200 projetos no GitHub, com cerca de 180 funções Lambda na AWS. Cada projeto tinha seu próprio arquivo de CloudFormation, entradas no API Gateway, Lambdas e recursos como SQS, tabelas no DynamoDB e buckets no S3. Era um ambiente complexo para um time pequeno, com menos de 15 pessoas.

Desafio #1 — Conhecimento, Manutenção e Documentação

A primeira dificuldade foi gerir o conhecimento e a evolução desses projetos. Com o tempo, alguns serviços ficavam meses sem sofrer alterações. Quando o time precisava voltar a atuar neles, era necessário praticamente reconstruir todo o entendimento. É nesse momento que a falta ou as pendências de documentação de API, README e código cobra seu preço. Esse problema é ainda maior quando há rotatividade no time.

Desafio #2 — Manutenção tecnológica

Com muitos projetos, manter a tecnologia atualizada se tornou um desafio. Cada microserviço importava diversas bibliotecas externas que precisavam de atualização. Além disso, a stack base (Node.js, no nosso caso) também precisava evoluir.

O problema ficou evidente quando a AWS anunciou o fim do suporte ao Node.js 12. Tínhamos mais de 100 projetos que precisavam migrar para o Node 14. Em vários casos, o conjunto de bibliotecas externas e as mudanças no Node exigiram muitas horas de ajustes, gerando impacto no consumo das Lambdas (Mais detalhes nesse post).

Ficou claro que esse processo iria se repetir continuamente e que não haveria condições de manter tantos projetos isolados. Um exemplo: nossa plataforma de notificações era dividida em 5 projetos distintos — todos precisaram ser migrados e ajustados.

Desafio #3 — Monitoramento e gestão

Quanto mais serviços distintos, maior a necessidade de criar dashboards e alarmes específicos para acompanhar requisições, erros e latência. Gráficos agregados escondem problemas: serviços com alto volume mascaram problemas dos serviços menores.

Fazer a gestão de mais de 180 Lambdas se tornou uma tarefa bastante difícil. Mesmo usando o Elastic para observabilidade, percebemos que projetos mais agrupados eram mais fáceis de monitorar — era mais simples visualizar APIs com pior desempenho ou maior número de erros.

Desafio #4 — Dependências

Quando se desenha um micro-serviço tudo é lindo. Na prática, o dia a dia vai corroendo essa separação e, com o tempo, os serviços passam a depender uns dos outros. De repente, um problema em um serviço paralisa vários outros — um clássico “monolito distribuído”.

Essa dependência foi outra razão para migrarmos para o conceito de “menos é mais”. Começamos a agrupar projetos e substituir chamadas entre APIs (HTTP) por chamadas internas (SDK). Se a chamada invadisse um domínio muito distinto, mantínhamos a separação. Caso contrário, a unificação corrigia o padrão de monolito distribuído.

Esse modelo caminha para o conceito de **Monolito Modular**: simplifica a arquitetura, reduz a complexidade e torna o desenvolvimento mais natural, evitando problemas típicos da comunicação HTTP

Desafio #5 — "Fogo Amigo"

Uma extensão do problema de dependências é o “fogo amigo”: quando um serviço sobrecarrega outro internamente. Tivemos um caso assim em uma liberação que causou carga suficiente para superar o limite de 1.000 execuções simultâneas de Lambdas na AWS. A Figura 1 mostra o número de chamadas rejeitadas por hora nesse dia (17/12/24).

Figura 1 — Mais de 50 mil invocações rejeitas geradas por "fogo amigo"

Como ação emergencial, aumentamos o limite de Lambdas e a correção do serviço ofensor. Mas o aprendizado nesse tipo de cenário é que a arquitetura de micro-serviços precisa de proteções que quase sempre são pensadas para o mundo externo como quotas, circuit breakers e rate-limit. E isso é complexidade que pode ser evitada através do desenho dos componentes da arquitetura.

O objetivo é o equilíbrio

Quando se trata de arquitetura, quase sempre o equilíbrio é o melhor caminho. Na Wiipo, mantemos o conceito de micro-serviços para serviços de grande volume e Monolito Modular para os demais projetos. E isso já pode ser expressado em números:

• Mais 60 projetos arquivados no GitHub com as unificações
• Redução de mais de 40 Lambdas
• Redução de recursos da AWS (tabelas Dynamo, RDS, etc)

Até mesmo em um monolito que absorvemos há dois anos estamos buscando esse equilíbrio. Separamos o mesmo em diferentes grupos de containers com funções específicas. Ou seja, ele opera como um Monolito Modular na execução, embora no código seja apenas um projeto. O próximo passo é separar os domínios no código para melhorar métricas como consumo de memória, CPU, latência e tempo de elasticidade.

Isso não significa abandonar microserviços: um dos nossos projetos que atende mais de 2M de usuários está sendo avaliado para divisão em dois ou mais serviços. Mas agora, essa decisão é tomada com base em dados concretos — custo, gestão e real necessidade de separação.