Recentemente, esbarrei com um post no Reddit de uns dois anos atrás a partir do dia em que escrevo este artigo (27/02/2025).
Basicamente, ele cita um case de sucesso onde a Amazon Prime Video deixou de usar uma arquitetura de microserviços e voltou para um monólito, gerando uma economia significativa para a empresa.
Acredito que qualquer desenvolvedor sabe que, nos últimos tempos, criou-se uma crença muito forte de que microserviços são uma bala de prata para garantir escalabilidade (eu incluso). Ou seja, iniciar um projeto já com microserviços seria o caminho certo para garantir seu sucesso a longo prazo.
Entretanto, o que esse case da Amazon mostra é que nem sempre isso é verdade — nem mesmo para Big Techs, que geralmente têm muitos recursos, milhões de usuários e, em teoria, deveriam ter uma arquitetura altamente escalável.
Só que microserviços não significam necessariamente escalabilidade. O que realmente dita a escalabilidade de um projeto é a capacidade de modularização dos componentes essenciais para seu funcionamento.
Histórico e Motivação para Microserviços
A arquitetura de microserviços surgiu como uma resposta aos desafios enfrentados por grandes sistemas monolíticos, que se tornavam difíceis de escalar e manter conforme cresciam. Empresas como Netflix e Spotify adotaram essa abordagem para facilitar deploys independentes, melhorar a resiliência e permitir que times trabalhassem de forma mais autônoma.
Modularização como Premissa
Independentemente de estar trabalhando com um monólito ou com microserviços, modularizar deve ser uma preocupação constante. Estamos falando de isolamento de escopo e da responsabilidade única de cada peça dentro do sistema. Esse conceito se encaixa no que chamamos de Modular Monolithic Architecture.
Essa abordagem segue um dos princípios mais importantes da engenharia de software: o KISS (Keep It Simple, Stupid). Manter a estrutura do código simples e bem organizada permite que o time compreenda melhor as partes fundamentais do projeto. E, com essa visão mais ampla, fica muito mais fácil tomar decisões informadas sobre quando (e se) um módulo deve ser transformado em um microserviço.
Vantagens e Desvantagens dos Microserviços e Monólitos
| Característica | Microserviços | Monólito |
|---|---|---|
| Escalabilidade | Alta, mas complexa | Limitada, mas mais simples |
| Complexidade (aqui acho que até depende um pouco do tamanho do time) | Alta (orquestração, comunicação) | Menor (tudo no mesmo sistema) |
| Manutenção | Pode ser mais fácil por ser modular | Pode se tornar difícil conforme cresce |
| Desempenho | Pode sofrer com latência de rede | Melhor performance interna |
| Tamanho do Time | Melhor para times grandes e distribuídos | Mais adequado para times menores |
Microserviços Quando Necessário
A chave aqui não é evitar microserviços, mas sim não começar um projeto já fragmentado em dezenas de pequenos serviços sem uma necessidade real. Alguns fatores devem ser levados em conta antes de tomar essa decisão, sendo os principais:
- A importância do módulo: É algo crítico para o sistema? Precisa de uma escalabilidade específica?
- A frequência de uso: O serviço será chamado o tempo todo ou é algo esporádico?
- O tamanho do time: Esse é um ponto crucial. De nada adianta ter uma arquitetura de microserviços se o time é pequeno e precisa conhecer e trabalhar em todos eles. Assim como não faz sentido ter um monólito enorme com um time gigante brigando por Pull Requests intermináveis e gerando gargalos na entrega.
A Uber por exemplo teve que primeiro IDENTIFICAR que a arquitetura de monolito não era mais suportável.
É uma grande empresa que iniciou de um monolito, mas que teve que, a medida que eles cresciam os microserviços foram se tornando necessários. Aí que o case de sucesso em escalabilidade se faz. Um dos grandes problemas principalmente de iniciantes é querer resolver problemas que não existem ainda e assim se cresce todo um hype em cima de uma solução bala de prata que não está atacando nenhuma dor do projeto em si. A solução não se comunica com o que o projeto é.
Service-Oriented Architecture: Scaling the Uber Engineering Codebase As We Grow
Conclusão
No fim das contas, modularização bem feita e uma visão prática da arquitetura são muito mais importantes do que seguir modas cegamente. Microserviços não são sinônimo de escalabilidade, assim como monólitos não são sinônimo de sistemas ruins e antiquados.
Precisamos de um equilíbrio entre simplicidade e organização é o que realmente garante que um sistema seja sustentável no longo prazo. Nossa posição como desenvolvedores é compreender necessidades e atuar sobre elas. Entender as características do nosso produto ou do produto em que trabalhamos para nos perguntar de fato do que precisamos. Toda tendência é bacana para termos o conhecimento, mas não significa que nosso projeto pede por ela.
Top comments (0)