O mercado global de service mesh vale US$ 1,79 bilhão em 2026 e cresce a um CAGR de 18,27% ao ano. No mesmo período, a adoção caiu de 18% para 8% segundo a pesquisa CNCF 2025. Essa contradição define a situação da service mesh em 2026: o mercado cresce porque o problema é real, mas as equipes largaram a solução porque a implementação era cara demais. A boa notícia é que a arquitetura mudou — e o momento para repensar essa decisão chegou.
Por que as equipes abandonaram a service mesh
O padrão sidecar — um proxy Envoy por pod — foi o modelo dominante entre 2019 e 2023. O problema: cada sidecar consomia de 50 a 100 MB de memória por pod. Em um cluster com 1.000 pods, isso representava 70 GB de memória desperdiçada apenas com infraestrutura de observabilidade e roteamento. A pesquisa CNCF 2025 com 689 respondentes confirmou: 62% das equipes citaram “overhead de recursos” como principal razão para abandonar ou não adotar service mesh. Resultado: 42% das organizações estão consolidando microsserviços de volta a unidades maiores — uma reavaliação arquitetural ampla motivada pelo custo operacional, não pelo abandono dos conceitos.
A virada: Istio Ambient Mode e eBPF eliminam o overhead
O Istio Ambient Mode atingiu GA com o Istio 1.22 e ganhou suporte multicluster em março de 2026, anunciado no KubeCon + CloudNativeCon Europe. A arquitetura é fundamentalmente diferente: em vez de um sidecar por pod, o Ambient Mode usa um ztunnel por nó (DaemonSet) para mTLS L4, com waypoint proxies opcionais para funcionalidades L7. O resultado prático é brutal: o ztunnel consome 12 MB a 1.000 RPS versus 50–100 MB dos sidecars tradicionais. Em clusters de produção, a economia de memória supera 80%.
O Cilium, baseado em eBPF, chegou como alternativa de alta performance. Benchmarks diretos em clusters de 3 nós e 100 serviços mostram: Cilium entrega p50 de 1,4 ms (vs. 2,1 ms do Istio Ambient) e 40–60% menos latência que o Istio sidecar tradicional. Hoje, o Cilium é o CNI padrão no Google GKE Autopilot, recomendado pela AWS EKS e adotado pelo Azure AKS como “CNI Powered by Cilium” — com mais de 5.000 deployments em produção globalmente. A consolidação como padrão de mercado está acontecendo agora, em 2026.
Istio vs. Cilium: qual escolher para sua realidade
A escolha entre Istio Ambient e Cilium eBPF depende do caso de uso dominante na sua arquitetura:
- Cilium é a escolha certa quando performance bruta e integração Kubernetes-nativa são prioritárias. Menor latência (p50 1,4 ms), menor overhead por nó, e integração nativa com políticas de rede.
- Istio Ambient se destaca em ambientes que exigem funcionalidades L7 avançadas — circuit breaking, fault injection, traffic mirroring, e o novo Gateway API Inference Extension para roteamento de workloads de machine learning.
- Para empresas brasileiras no setor financeiro e healthtech, onde a LGPD e as normativas do Banco Central exigem rastreabilidade de tráfego e logs auditáveis, o Istio oferece uma trilha de auditoria mais madura e integração com ferramentas de observabilidade existentes.
O novo driver de adoção: service mesh para workloads de IA
O verdadeiro motor do crescimento de mercado está em um caso de uso que não existia em 2022: 66% das organizações já rodam workloads de IA generativa no Kubernetes, segundo dados do KubeCon Europe 2026. Isso criou demanda imediata por infraestrutura de roteamento capaz de distinguir tráfego de inferência de tráfego de aplicação convencional. O Istio 2026 responde com duas inovações: o Gateway API Inference Extension, que permite roteamento por modelo e prioridade de inferência dentro da mesh, e o AgentGateway (experimental), um data plane específico para tráfego entre agentes de IA. A service mesh deixou de ser infraestrutura de microsserviços para se tornar infraestrutura de IA.
Conclusão
A service mesh não morreu — ela sobreviveu à crise dos sidecars e emergiu mais leve, mais rápida e com casos de uso mais poderosos. Para equipes que abandonaram a tecnologia entre 2021 e 2023 por causa do overhead, 2026 é o momento de reavaliar: Istio Ambient Mode e Cilium eBPF resolveram o problema que causou o abandono. E com 66% das organizações rodando GenAI no Kubernetes, a pergunta não é mais “precisamos de service mesh?”, mas “estamos prontos para gerenciar tráfego de agentes sem uma?”