"Add a service mesh" has become the Kubernetes equivalent of "make everything private." The reasoning seems unassailable: mTLS, observability, traffic management — all handled transparently. But the recommendation rarely comes with the operational bill attached.
At 1,000 pods, traditional Envoy sidecars consume approximately 70 GB of memory — before a single byte of application traffic. The latency overhead of Istio's traditional sidecar mTLS: +166% at high load. Compared to 8% for Istio Ambient and 33% for Linkerd.
#
What a Service Mesh Actually Provides
mTLS — encrypted, mutually authenticated pod-to-pod communication #
Traffic management — weighted routing, canary, fault injection, circuit breaking #
Observability — automatic golden signals for every service-to-service call #
Policy — authorisation rules enforced at the network layer
What it does NOT provide: free performance, simpler operations, automatic security, or a substitute for application-level observability.
#
The Real Cost
Plus: operational overhead of debugging Envoy config, pilot reconciliation, sidecar injection, and mesh upgrade coordination.
#
When a Mesh Is Unnecessary
< 10 services — NetworkPolicy + cert-manager covers it at a fraction of the cost #
Dev/staging clusters — adds debugging surface without production benefit #
Monolithic deployments — one service-to-service call doesn't justify a mesh #
Teams without dedicated platform ownership — the mesh will add more incidents than it prevents
#
When a Mesh IS Worth It
- 50+ services across multiple teams with genuine policy requirements
- Canary deployments and traffic shaping at scale
- Regulated environments with explicit mTLS and auditability requirements
#
The 2026 Landscape Has Changed
Istio Ambient Mode (GA in 1.25): per-node ztunnel handles L4 mTLS, 90%+ memory reduction, 8% latency overhead.
Cilium Service Mesh: eBPF at kernel level, no sidecar, 40–60% network overhead reduction vs traditional proxies.
If overhead was your objection before mid-2025, re-evaluate.
#
Lighter Alternatives
mTLS: cert-manager + NetworkPolicy + IRSA/Workload Identity #
Observability: OpenTelemetry with DaemonSet collector #
Traffic management: Argo Rollouts + NGINX Ingress weighted routing
#
Read the Full Article
This is a summary of the third post in the Cloud Defaults Reconsidered series. The full article includes the complete decision framework, detailed cost breakdowns, operational overhead analysis, and architecture selection guide:
**👉 **Service Mesh Everywhere? — Full Article
The full article includes:
- Memory and latency overhead calculations at scale
- Operational debugging scenarios and upgrade coordination costs
- Common misconceptions debunked (mTLS ≠ mesh, "free" observability, upgrade safety)
- When a mesh is unnecessary vs when it's justified
- Istio Ambient vs Cilium vs Linkerd vs traditional sidecars comparison
- Complete 3-step decision framework
- Lighter alternatives that close 80% of the gap