1 – Não seja extremista
Temos a mania — e até um sonho inalcançável — de encontrar um padrão que resolva 100% dos nossos problemas. Com arquitetura de software, isso não é diferente.
O ponto aqui é simples: você não precisa adotar um padrão e morrer abraçado com ele. Seu sistema não precisa ser apenas um monolito ou exclusivamente composto por microsserviços.
A realidade do mercado mostra que, na maioria dos casos, existe uma mescla dessas arquiteturas, justamente para extrair o melhor que cada uma pode oferecer.
2 – Alinhamento estrutural
Empresa e equipe precisam estar alinhadas em relação às linguagens, ferramentas e diretrizes técnicas.
Um dos problemas que microsserviços podem causar é a mistura descontrolada de tecnologias. Imagine uma empresa sem padrões bem definidos: um desenvolvedor cria um microsserviço em uma linguagem X, outro cria outro serviço na linguagem Y, e assim por diante.
Quando se percebe, pode ser tarde demais. Surgem problemas como:
- Apenas uma pessoa domina determinado sistema;
- Sistemas sem suporte porque ninguém conhece a linguagem usada;
- Falta de controle e governança técnica.
Microsserviços exigem maturidade organizacional, não apenas técnica.
3 – Reutilização é um benefício
Um ponto que considero extremamente benéfico é a reutilização de sistemas.
Um exemplo simples seria um microsserviço responsável por validar CPF e CNPJ em bases governamentais. Esse mesmo serviço poderia ser reutilizado:
- No cadastro de clientes;
- No RH, para validar dados de funcionários;
- No setor de compras, para verificar dados de fornecedores.
Constrói-se uma única aplicação que passa a ser utilizada por diversos outros sistemas, aumentando o retorno sobre o investimento.
4 – A importância da documentação
Se documentação já é importante em qualquer arquitetura, em microsserviços ela se torna crítica.
Quando um microsserviço tem seus campos de entrada ou saída alterados e a documentação não acompanha essas mudanças, seu uso se torna extremamente difícil. O que deveria ser simples pode virar uma grande dor de cabeça.
Sem documentação confiável e contratos bem definidos, microsserviços rapidamente se tornam inviáveis.
5 – Testar é difícil
Em um monolito, os testes tendem a ser mais práticos, pois todo o código está no mesmo contexto. Comportamentos inesperados são mais fáceis de identificar.
Em microsserviços, a complexidade aumenta. É necessário:
- Testar cada serviço isoladamente;
- Testar a comunicação entre eles;
- Testar o fluxo completo de ponta a ponta.
Isso dá trabalho. Por isso, logs, métricas e monitoramento deixam de ser opcionais e passam a ser essenciais.
6 – Isolamento de recursos
Um dos problemas que microsserviços ajudam a resolver é o consumo desigual de recursos.
Imagine uma aplicação onde apenas uma funcionalidade consome muitos recursos. Em um monolito, pode ser necessário aumentar os recursos de toda a aplicação. Já com microsserviços, é possível isolar essa funcionalidade em um serviço separado e alocar apenas os recursos necessários.
Além disso, esse isolamento permite:
- Atualizar versões de linguagem de forma incremental;
- Usar tecnologias mais adequadas para problemas específicos;
- Evoluir sistemas legados aos poucos, sem reescrever tudo de uma vez.
7 – Evolução é algo natural
Muito se fala que, para adotar microsserviços, é necessário ter contextos muito bem definidos. Em parte, isso é verdade. Porém, no mundo real, dificilmente começamos um projeto com tudo perfeitamente mapeado.
Muitas empresas iniciam sistemas com escopo incompleto, regras de negócio ainda em construção e diversos pontos em aberto. Nesse cenário, é comum adotar um padrão sem saber exatamente se ele será o mais adequado no longo prazo.
Na minha experiência, ter tudo bem definido ajuda muito, mas não deve ser visto como um impeditivo para o uso de microsserviços. Com o passar do tempo, contextos mudam: um microsserviço pode ser dividido em outros, crescer, ser unificado ou até abandonado.
Arquitetura é algo vivo. O sistema naturalmente cresce e evolui junto com o negócio.
8 – De solução a problema (e vice-versa)
Os pontos anteriores mostram que microsserviços têm prós e contras. A adoção dessa arquitetura é, inevitavelmente, um depende, ou seja, uma decisão contextual.
Cada aplicação precisa ser analisada individualmente. Um exemplo famoso é o da Amazon Prime Video, que em um determinado contexto acabou migrando de microsserviços para um monólito.
Falando em experiência própria, um projeto do qual participo tem sua arquitetura totalmente baseada em microsserviços. As funcionalidades operam de forma independente, o que aumenta a resiliência: se um serviço falha, as demais partes continuam funcionando, reduzindo o impacto do problema. Ao mesmo tempo, posso afirmar que a equipe enfrentou vários dos desafios e problemas listados neste artigo.
No fim, microsserviços não são um objetivo em si, mas uma ferramenta. Usados no contexto errado, podem virar um grande problema. Usados corretamente, podem ser uma excelente solução.
Top comments (0)