Para a maioria dos times, o monolito modular é o melhor ponto de partida. Ele sai como uma única unidade de deploy, e o build garante as fronteiras entre módulos dentro do código. Microsserviços em Kubernetes passam a compensar quando vários times precisam liberar suas partes sem depender um do outro, e cada time cuida do seu serviço inteiro.
Antes desse ponto, a infraestrutura extra quase sempre só soma sistemas para operar. A página de engenharia de plataforma descreve o trabalho em volta dessa escolha, e vale tomá-la com critério antes de subir o primeiro cluster.
Qual a diferença entre monolito modular e microsserviços?
A diferença está em onde as fronteiras vivem quando o código está rodando. Os dois estilos dividem a aplicação por capacidade de negócio. O que muda é se essa divisão também vira uma divisão de deploy.
O guia de arquitetura da Microsoft define microsserviços como componentes pequenos e pouco acoplados, que um único time pequeno consegue escrever e manter. Cada serviço deve implementar uma única capacidade de negócio dentro de um bounded context. Cada um tem seu próprio codebase. O serviço guarda os próprios dados e fala com os outros por APIs bem definidas, que escondem o que acontece por dentro.
O monolito modular usa a mesma ideia de bounded contexts. Só que todos os módulos saem num único artefato. Um módulo chama o outro por interfaces explícitas, dentro do mesmo processo. Quem garante a fronteira é o build, por exemplo com uma regra de dependências que quebra quando um módulo importa algo interno de outro.
Tem um jeito simples de enxergar a escolha. Os dois estilos decidem como o código se organiza. Microsserviços também obrigam você, desde já, a fazer deploy de cada peça separada e a operar tudo o que torna esse deploy separado seguro. O monolito modular toma a primeira decisão agora e deixa a segunda em aberto.
Por que tantos times escolhem microsserviços?
Porque os benefícios são reais, e o guia da Microsoft os descreve bem. O primeiro é agilidade. Como cada serviço tem deploy independente, dá para atualizar um serviço sem refazer o deploy da aplicação inteira e fazer rollback desse serviço se algo der errado.
O guia compara isso com aplicações tradicionais. Nelas, um bug em uma parte pode travar o processo de release inteiro. Features que não têm nada a ver com o bug ficam paradas enquanto a correção passa por integração e testes.
O segundo benefício é o tamanho do time. Um serviço com codebase próprio, nas mãos de um time pequeno, é algo que esse time entende por completo. Ele muda o serviço sem negociar com mais ninguém. O guia também cita que os serviços podem ser poliglotas. Não precisam compartilhar stack, bibliotecas nem frameworks.
Agora olhe o que esses benefícios pressupõem. Todos eles se pagam quando os releases de vários times atrapalham uns aos outros. Um único time entregando um único produto raramente tem o release travado pelo bug de outro time, já que não existe outro time. Para esse time, o deploy independente resolve um problema que ele ainda não tem. E a liberdade poliglota vira custo quando as mesmas poucas pessoas precisam manter todas as stacks.
Quanto custa a infraestrutura extra dos microsserviços?
Custa um conjunto de sistemas novos para operar, e a Microsoft é direta sobre isso. O guia abre dizendo que uma arquitetura de microsserviços bem-sucedida exige uma mudança profunda de mentalidade. E que isso vai além de quebrar a aplicação em serviços menores.
Depois o guia lista os componentes que aparecem ao lado dos serviços. A orquestração agenda e faz deploy dos serviços entre os nós, se recupera de falhas e faz autoscaling conforme a demanda. Normalmente quem faz isso é uma plataforma de orquestração de containers como o Kubernetes. Um API gateway vira a porta de entrada e cuida de temas transversais, como autenticação e logging. Proxies como Envoy e Nginx cuidam do tráfego entre serviços. Plataformas de mensageria como Apache Kafka ou Azure Service Bus levam os eventos assíncronos.
A observabilidade passa a pedir logging centralizado e tracing distribuído, que acompanha cada requisição atravessando as fronteiras entre serviços. E os dados ficam descentralizados, porque cada serviço é dono dos seus dados e do seu schema.
Cada item dessa lista é um sistema que alguém precisa rodar e atualizar, e alguém precisa atender o alerta quando ele quebra. Lado a lado, os dois estilos ficam assim.
| Tema | Monolito modular | Microsserviços em Kubernetes |
|---|---|---|
| Deploy | Um artefato, um pipeline | Um pipeline por serviço, mais o orquestrador |
| Porta de entrada | A própria aplicação | Um API gateway na frente de cada requisição |
| Chamadas entre partes | Chamadas em processo, pelas interfaces dos módulos | Chamadas de API entre serviços, muitas vezes via proxy ou broker de mensagens |
| Dados | Um banco, com tabelas que pertencem a cada módulo | Cada serviço é dono dos seus dados e do seu schema |
| Rastrear uma requisição | Logs e stack traces de um processo só | Logging centralizado e tracing distribuído |
| Escala | Escala a unidade inteira | Autoscaling de cada serviço conforme a demanda |
| Acoplamento de release | Todos os módulos saem juntos | Cada serviço sai no seu próprio ritmo |
A coluna da direita é o que garante a independência descrita na seção anterior. Se você não precisa dessa independência, está pagando por componentes cujo trabalho principal é tornar seguro o deploy independente. Pelo lado do cluster, vale ler também o que é Kubernetes e quando você não precisa dele.
Quando o Kubernetes deixa de compensar?
Deixa de compensar quando não há times suficientes se bloqueando para justificar o custo fixo. Com cluster, gateway, broker e tracing no lugar, esse custo quase não muda. O benefício cresce com a quantidade de times que, sem a separação, bloqueariam uns aos outros. Daí sai um teste prático.
Separar em serviços tende a valer a pena quando vários times travam os releases uns dos outros com frequência num codebase compartilhado. Esse é o problema que o argumento de agilidade da Microsoft resolve. Também vale quando uma parte do sistema tem um perfil de carga muito diferente do resto e precisa de autoscaling próprio.
Mas só se sustenta se cada time consegue assumir o deploy e o on-call do que entrega. E se alguém é dono do orquestrador e da stack de tracing como produto. Normalmente é um time de plataforma, e a divisão de papéis está em engenharia de plataforma vs DevOps vs SRE.
Deixa de compensar quando um único time é dono do produto inteiro. Ou quando a maioria das mudanças atravessa as fronteiras dos módulos de qualquer jeito. Também deixa de compensar quando o upgrade do cluster e a configuração do gateway não são trabalho de ninguém. Nesse caso eles são feitos tarde, ou nunca.
Existe um caminho do meio para quando só uma peça precisa mesmo ficar separada. A Microsoft cita plataformas gerenciadas como o Azure Container Apps, que oferecem orquestração gerenciada e escala embutida. Segundo o guia, essas ferramentas reduzem a complexidade de deploy e o overhead operacional. Rodar um único serviço extraído numa plataforma gerenciada dá deploy independente para essa peça, sem que você precise operar um cluster de Kubernetes para isso.
Como manter a opção de separar depois?
Escreva o monolito como se as fronteiras dos módulos fossem fronteiras de serviço. A descrição de serviço do guia da Microsoft funciona como checklist para um módulo. Ele é dono de uma capacidade de negócio e dos seus dados. As outras partes só chegam nele por uma interface definida.
Na prática, dê a cada módulo uma interface pública e deixe todo o resto interno. Mantenha as tabelas de cada módulo privadas, para que nenhum outro módulo faça query nelas direto. Isso espelha o ponto do guia de que ser dono dos dados reduz as dependências entre serviços. Depois, adicione uma checagem no build que falha quando um módulo importa algo interno de outro. Com isso no lugar, extrair um módulo mais tarde é colocá-lo atrás de uma API de rede. Você não precisa desembaraçar tabelas compartilhadas antes.
Uma checagem que você pode rodar hoje: escolha um módulo e liste quais tabelas dele outros módulos leem direto. Se a lista não está vazia, a fronteira existe só no diagrama. Esse é o primeiro ponto a corrigir, com ou sem planos de separar.
Antes de separar qualquer coisa, meça a entrega. Se o lead time e a taxa de falha em mudanças estão saudáveis, o problema de release travado que os microsserviços resolvem provavelmente não está lá. O texto sobre métricas DORA mostra como medir os dois.
Se os números mostram times se travando, eu extrairia só o módulo que causa o bloqueio e decidiria cedo quem é dono da plataforma por baixo, um tema que aparece em plataforma interna de desenvolvimento: construir ou comprar. Com vários serviços rodando, promover releases entre ambientes com segurança vira um trabalho à parte, e esse é o assunto de Argo CD e Kargo.
Fontes
- learn.microsoft.com, consultada em 21 de outubro de 2026 (sha256 5d8eeff67749).