O que é service mesh — e quando você realmente precisa de um
Em 2022 aprendi Istio. Demorei semanas para entender por que ele existe. Quando entendi, virei crítico dele — não porque é ruim, mas porque a maioria não precisa.
Aprendi Istio em 2022.
Levei três semanas para entender o que ele fazia. E depois que entendi, passei o resto do tempo questionando se era necessário.
Service mesh é uma camada de infraestrutura que intercepta todo tráfego entre serviços. Em vez de cada serviço implementar: retry, circuit breaker, mTLS, rate limiting, observabilidade — o mesh faz isso para todos de forma transparente.
A implementação mais comum: sidecar proxy. Junto com cada pod da sua aplicação, o Kubernetes injeta um proxy (Envoy no caso do Istio) que intercepta todo tráfego de entrada e saída.
[Serviço A] → [Envoy Sidecar A] --rede-- [Envoy Sidecar B] → [Serviço B]
O serviço não sabe que o proxy está lá. O proxy resolve: autenticação mútua (mTLS), retry automático, circuit breaking, observabilidade de cada request.
O problema que resolve:
Em arquitetura com dezenas de microserviços, cada serviço implementando retry, timeout, circuit breaker, observabilidade no próprio código significa: inconsistência, duplicação, e comportamento difícil de debugar entre serviços escritos em linguagens diferentes.
Service mesh centraliza isso na infraestrutura. Você configura a política uma vez, ela se aplica a todos os serviços independente de linguagem.
O que aprendi que os tutoriais não dizem:
Service mesh tem custo alto. Cada pod ganha um container extra (sidecar). CPU e memória adicionais. Complexidade de debugging aumenta exponencialmente — quando algo não funciona, o problema pode estar no serviço, no sidecar, na configuração do mesh.
E o benefício só se justifica quando você tem:
- Comunicação service-to-service significativa (não apenas para API gateway externo)
- Múltiplas linguagens onde implementar na biblioteca seria despadronizado
- Time com capacidade de operar e debugar a infraestrutura adicional
Se você tem 3 serviços em Go e quer circuit breaker — use biblioteca. Se você tem 30 serviços em 6 linguagens e um time de plataforma dedicado — service mesh faz sentido.
A pergunta que fica:
Você não precisa do máximo de capacidade que o problema pode exigir — você precisa do que o problema atual exige.
Service mesh resolve problema de dezenas de serviços com requisitos de segurança e observabilidade complexos. Antes de chegar lá, provavelmente tem problemas mais urgentes.
Aprendi Istio não porque precisava na época, mas porque queria entender onde ele se encaixa. O entendimento mais útil que saiu foi: é uma ferramenta para um estágio específico de maturidade de plataforma. Antes desse estágio, adiciona mais complexidade do que resolve.