Cloud não escala times imaturos e microserviços também não

Seguindo a linha de pensamento que escrevi no último artigo quero abordar outro aspecto da imaturidade de equipes de desenvolvimento, pensar que microserviços resolvem tudo.

Esta conversa é muito comum no mundo da engenharia: quando as coisas começam a doer, a solução é arquitetural.

• Deploys lentos? Microserviços.
• Sistema difícil de evoluir? Microserviços.
• Conflitos constantes entre times? Microserviços.

Só que quase nunca a dor é causada pela arquitetura em si, mas ela costuma ser consequência de algo mais estrutural: ausência de disciplina, domínio mal modelado, responsabilidades difusas, código sem limites claros.

Quando você leva um sistema para a cloud, você ganha elasticidade, automação, serviços gerenciados. Mas também ganha exposição e tudo fica mais explícito: sua falta de observabilidade, sua governança frágil, sua política de acesso mal definida, sua incapacidade de medir custo.

Com microserviços acontece algo muito parecido.

No papel parece simples: quebrar o sistema em partes menores, permitir deploy independente, escalar só o que precisa, dar autonomia aos times. Na prática, você troca complexidade interna por complexidade distribuída. O que antes era uma chamada de método passa a ser uma requisição de rede sujeita a latência, timeout e falhas parciais. O que antes era uma transação local vira um problema de consistência entre serviços e o que antes era um stack trace direto vira uma investigação em logs, métricas e traces espalhados por múltiplos componentes.

Um monolito mal organizado dói, mas ainda é contido, pois está em um único repositório, em um único processo, sob um único modelo de execução. Um conjunto de microserviços mal pensados espalha a desorganização pela rede e agora você precisa versionar contratos, manter compatibilidade entre APIs, orquestrar pipelines independentes, coordenar deploys e garantir que ninguém quebre o fluxo de outro serviço sem perceber.

Se já não existe clareza de domínio dentro de um único código, o que faz alguém acreditar que haverá clareza quando esse mesmo domínio for distribuído em cinco, dez ou vinte serviços?

Muitas vezes, a decisão por microserviços não nasce de uma necessidade técnica real, mas de um incômodo organizacional, pois times que não conseguem colaborar tentam se isolar via arquitetura, e daí conflitos de responsabilidade viram fronteiras artificiais de serviço, a falta de modularização interna vira “vamos separar em serviços”.

Ganhar maturidade é necessário

É por isso que a conversa sobre arquitetura deveria começar antes do diagrama.

Antes de discutir gateways, filas, malhas de serviço e orquestração, talvez a pergunta mais honesta seja: conseguimos manter um monolito saudável? Temos limites internos bem definidos? Entendemos nosso domínio de negócio de forma clara? Existe disciplina de testes, revisão e ownership?

Isso não significa que microserviços não façam sentido. Eles fazem (e muito) quando há pressão real por escala independente, quando os domínios estão claramente delimitados, quando há maturidade operacional para lidar com falhas distribuídas e quando a organização está preparada para assumir o custo adicional de coordenação.

A cloud não é um atalho para boa engenharia e microserviços também não são. Ambos são multiplicadores, se a base é sólida, eles ampliam eficiência, se a base é frágil, eles ampliam os problemas.

Talvez a decisão mais madura não seja perguntar “monolito ou microserviços?”.
Talvez seja perguntar “estamos prontos para o nível de responsabilidade que essa arquitetura exige?”.

Começar com um monolito bem estruturado não é retrocesso e sim disciplina. É investir em modelagem, modularização e clareza antes de distribuir complexidade pela rede. E quando a pressão for concreta, e não apenas estética, extrair serviços passa a ser consequência natural.