Comece com um monólito bem organizado. Microsserviços resolvem um problema de equipe, times demais pisando no mesmo código, antes de resolverem qualquer problema de escala. Se você tem um time de cinco pessoas, a arquitetura distribuída vai custar mais do que entregar.
A conversa sobre microsserviços costuma começar pelo lado errado. Alguém lê que a Netflix tem centenas de serviços independentes e conclui que o sistema da empresa também deveria ter. Só que a Netflix chegou lá empurrada por um problema que a maioria das empresas não tem: milhares de engenheiros que não podem ficar esperando uns aos outros para publicar uma alteração.
O custo que ninguém mostra no diagrama
No slide, microsserviços são caixinhas limpas ligadas por setas. Na operação, cada seta é uma chamada de rede que pode falhar, demorar ou responder pela metade.
Quando você quebra um sistema em serviços, ganha independência de deploy e paga com:
- Transações distribuídas. O que era um
BEGIN ... COMMITvira uma coreografia de compensações. Pedido criado, pagamento falhou, estoque já foi reservado. E agora? - Depuração em vários lugares ao mesmo tempo. Uma requisição lenta atravessa quatro serviços. Sem rastreamento distribuído, você está caçando no escuro.
- Ambiente local. O desenvolvedor novo precisa subir sete serviços para testar uma tela.
- Versionamento de contratos. Mudar um campo de resposta deixa de ser um commit e vira uma negociação entre times.
Esse custo se paga quando você tem times o bastante para que o gargalo real seja a coordenação humana. Antes disso, é imposto puro.
O monólito modular, que quase ninguém tenta
Existe um degrau entre “tudo misturado” e “tudo separado”, e é onde a maioria dos sistemas deveria viver por muito tempo. Um único processo, um único banco, mas com fronteiras internas levadas a sério.
Na prática significa três coisas. Cada domínio (cobrança, catálogo, usuários) vive no seu próprio módulo, com a própria camada de acesso a dados. Módulos conversam por interfaces explícitas, sem fuçar as tabelas uns dos outros. E nada de JOIN entre tabelas de domínios diferentes: se você precisou, a fronteira está no lugar errado.
Feito assim, no dia em que um módulo precisar sair para um serviço próprio, ele sai. As dependências já estão mapeadas e a extração vira trabalho de alguns dias, não de trimestre.
Sinais concretos de que chegou a hora
Não é sensação. É evidência:
- Deploys travando uns aos outros. Duas equipes esperam a fila de publicação da outra de forma rotineira.
- Perfis de escala muito diferentes. O módulo de relatórios consome oito vezes mais CPU que o resto, e você escala a aplicação inteira só para dar conta dele.
- Requisitos de disponibilidade diferentes. O checkout não pode cair. O painel administrativo interno pode ficar dez minutos fora sem drama nenhum.
- Tecnologia incompatível. Um pedaço do sistema precisa de processamento pesado que a linguagem principal não faz bem.
Um item da lista já justifica extrair aquele pedaço específico. Nenhum item da lista não justifica reescrever tudo.
Extraia um, não trinta
Quando a hora chega, o caminho seguro é sempre o mesmo. Escolha o módulo com a fronteira mais limpa e o menor acoplamento com o resto. Publique como serviço. Deixe o monólito chamá-lo. E observe o que quebra, porque alguma coisa vai quebrar, e é bem melhor descobrir com um serviço do que com quinze.
Se a primeira extração for tranquila, a segunda também será. Se for um pesadelo, você acabou de descobrir algo valioso pelo preço mais barato possível.
O que costuma dar mais resultado antes disso
Boa parte dos sistemas que “precisam de microsserviços” na verdade precisa de coisas bem menos glamourosas.
Índices no banco, para começar. Falo sério: a maioria dos gargalos que vira justificativa de arquitetura é uma consulta sem índice. Depois, cache no lugar certo, com invalidação pensada. Fila para o trabalho pesado, tirando envio de e-mail, geração de relatório e processamento de imagem do caminho da requisição do usuário. E, em último caso, um servidor maior. Escala vertical é feia, é limitada, e resolve muito mais casos do que a literatura admite.
Precisa de uma segunda opinião sobre a arquitetura antes de investir numa reescrita? A DCODER faz auditoria de arquitetura e desenvolve sistemas com atendimento direto do engenheiro responsável. Fale com o estúdio em dcoder.io.