O Que é um Service Mesh? Tirando a Lógica de Rede do Seu Código
Um service mesh é uma camada de infraestrutura que cuida da comunicação service-to-service, retries, criptografia e observabilidade fora do código da sua aplicação.
À medida que um conjunto de microservices cresce, cada serviço acaba reimplementando as mesmas preocupações de rede: retries, timeouts, mutual TLS, roteamento de tráfego, métricas. Um service mesh tira essa lógica do seu código e a coloca em uma rede de sidecar proxies, um ao lado de cada serviço, controlados centralmente. Seu código faz uma chamada simples; o mesh cuida do resto.
Os sidecars fazem o trabalho de rede
Um proxy roda ao lado de cada instância de serviço e intercepta seu tráfego de entrada e saída. Esses sidecars, coordenados por um control plane, aplicam retries, timeouts, criptografia e regras de roteamento sem que o serviço saiba.
O que ele descarrega do seu código
- Retries, timeouts e circuit breaking.
- Mutual TLS entre serviços.
- Modelagem de tráfego para rollouts canary e blue-green.
- Métricas, logs e traces uniformes para cada chamada.
Por que ele atrai em escala
Sem um mesh, cada time implementa resiliência e segurança de forma diferente em cada linguagem. Um mesh padroniza essas preocupações em um único lugar, então o comportamento é consistente e mudanças de política não exigem tocar em dezenas de codebases.
A vantagem no CI/CD
Um mesh pode deslocar tráfego gradualmente, o que torna canary e progressive deploys uma mudança de configuração em vez de código de aplicação. As pipelines guiam essas regras de rollout, aumentando o tráfego para uma nova versão e fazendo rollback automaticamente se as métricas degradarem.
A complexidade que ele adiciona
Um mesh é mais infraestrutura para operar, depurar e manter atualizada. Os sidecars adicionam latência e uso de recursos, e um mesh mal configurado pode quebrar todo o tráfego. Ele se paga em escala, mas é overhead para um punhado de serviços.
Testando com os sidecars presentes
O comportamento do mesh, mTLS, retries, roteamento, só aparece quando os sidecars rodam. Testes de CI realistas sobem o mesh para que política e roteamento sejam exercitados, o que é mais pesado do que testar um serviço nu e se beneficia de runners quentes.
Principais conclusões
- Um service mesh move rede, resiliência e segurança para dentro de sidecar proxies.
- Ele padroniza retries, mTLS e roteamento de tráfego entre muitos serviços.
- Ele viabiliza canary deploys guiados por config, mas adiciona complexidade operacional real.