Service mesh adoption grew through 2021 as Kubernetes became the standard for microservices deployment. The two dominant open-source service meshes are Istio and Linkerd, and their trade-offs are increasingly well understood.
What a service mesh adds
A service mesh handles the cross-cutting concerns of service-to-service communication: mutual TLS (mTLS) authentication, traffic management (load balancing, retries, circuit breaking, canary routing), and observability (metrics, distributed traces, access logs) without application code changes. The implementation uses sidecar proxies (Envoy for Istio, a lightweight Rust proxy for Linkerd) injected into each pod.
Istio's capabilities and complexity
Istio provides the most complete feature set of any service mesh: fine-grained traffic policies, external authorisation, rate limiting, extensible WebAssembly plugins. The cost is operational complexity: Istio's own control plane has multiple components (istiod, but previously Pilot, Mixer, Citadel), and the configuration model has a steep learning curve. Production Istio requires investment in understanding the control plane before managing it at scale.
Linkerd's simplicity focus
Linkerd 2.x (Buoyant) trades feature breadth for operational simplicity. The proxy is purpose-built (not Envoy), lighter on resources, and the operational model is simpler. Linkerd provides mTLS, traffic metrics, and basic traffic management but lacks some of Istio's advanced routing capabilities. For organisations whose primary goals are mTLS and observability, Linkerd's lower operational burden is the right trade-off.
The ambient mesh evolution
Istio's ambient mode (announced in 2022, GA in 2024) eliminates sidecars in favour of node-level proxies, reducing the resource overhead significantly. In 2021 the sidecar model is the production reality. The resource overhead of injecting an Envoy sidecar into every pod in a large cluster is measurable, 50-100MB memory per pod, and compounds at scale.