Uma startup de 5 engenheiros que adota microsserviços troca um repositório por quatro, um deploy por uma orquestração e um stack trace pela correlação de logs de quatro processos. A troca aparece na segunda semana, antes de qualquer ganho de escala.
O que os microsserviços entregam
Microsserviços é um estilo arquitetural: a aplicação vira serviços pequenos e independentes, cada um no seu processo, falando por API ou por mensagem. Cada serviço cobre uma capacidade de negócio e escala por conta própria.
Você assume junto o custo operacional dessa separação: pipeline de deploy por serviço, rastreamento de requisição entre processos e quatro sistemas que precisam responder juntos. Sam Newman trata desses efeitos em Building Microservices (O'Reilly, 2021), inclusive do "distributed monolith", que aparece quando os serviços dependem uns dos outros em tempo de execução.
A Netflix saiu do monolito com centenas de engenheiros atrás
Netflix e Amazon popularizaram a arquitetura de serviços. A Netflix migrou de um monolito que travava o crescimento e já contava com centenas de engenheiros para operar vídeo em escala. A Amazon montou times de plataforma cujo trabalho era esconder a complexidade de serviços do resto da empresa.
Martin Fowler e James Lewis descrevem o estilo em "Microservices" (2014) e aconselham começar por monólito enquanto o domínio ainda muda. Fowler reforça a ordem em "MonolithFirst" (2015): divida o código antes de dividir o processo.
Você tem de 3 a 8 engenheiros tentando provar que alguém paga pelo produto. Nenhum time de plataforma existe para absorver a complexidade, e o domínio muda depois de cada conversa com cliente.
O custo aparece na segunda semana
- Deploy vira coordenação. Você versiona API entre serviços, define ordem de publicação e mantém compatibilidade para trás. O pull request de uma tela vira três PRs em repositórios diferentes.
- Debug vira investigação. O erro que dava um stack trace agora pede logs de quatro processos cruzados pelo horário.
- Teste vira ambiente. Para provar que os serviços conversam, alguém mantém ambiente local montado ou um staging que cobra por hora.
- Onboarding vira contexto. Quem entra na segunda semana lê quatro códigos antes de mexer em produção.
Nicole Forsgren, Jez Humble e Gene Kim mostram em Accelerate (2018) que a velocidade de entrega acompanha a frequência de deploy e o lead time. Pipeline por serviço ataca os dois indicadores.
Quando os microsserviços pagam a conta
A separação rende em duas situações concretas:
- Times diferentes precisam publicar partes do sistema sem esperar um ao outro
- Uma parte do sistema pede cem vezes a carga da outra, como busca em relação ao cadastro de contas
A separação também rende quando os limites de domínio do produto já estão definidos e estáveis. Uma startup que ainda procura product-market fit não chega perto disso.
O monolito modular divide o código dentro de um processo só
Um monolito modular mantém um processo só e corta o código por domínio: cada módulo com sua camada de dados e suas interfaces. Você ganha fronteiras de código sem ganhar rede, contrato de API nem release em cadeia. Eric Evans chamou essas fronteiras de contextos delimitados em Domain-Driven Design (Prentice Hall, 2003).
Quando o monolito chegar no limite de escala, você extrai serviços de código que já está organizado por domínio. A extração vira trabalho de infraestrutura.
O padrão que sustenta startups em crescimento
Comece pelo monolito modular bem cortado. Cresça até o limite dele, mais alto do que a maioria imagina. Extraia um serviço quando um problema concreto aparecer: dois times travados no mesmo repositório, um componente que sozinho pede dez vezes a carga do resto, uma parte do sistema que precisa de outra stack.
Extrair serviço por preferência arquitetural troca um problema futuro por um presente, e o presente pesa para quem tem cinco engenheiros e doze meses de runway.
