Service Mesh

A service mesh moves cross-cutting networking concerns out of application code and into the platform: mutual TLS between services, retries with backoff, timeouts, circuit breaking, traffic splitting for canary releases, and request-level telemetry that feeds distributed tracing.

How it works

A mesh has a data plane, which carries the traffic, and a control plane, which pushes configuration and certificates to it. In the classic model a proxy runs as a sidecar next to every pod and intercepts its inbound and outbound traffic. Istio’s sidecar mode uses Envoy for this. Linkerd takes a different route and uses its own lightweight proxy written in Rust rather than Envoy.

Istio also offers ambient mode, which removes per-pod sidecars. A per-node proxy handles layer 4 traffic, including mTLS, and an optional waypoint proxy handles layer 7 features only for the namespaces that need them. Enrolling a namespace in ambient mode does not require restarting its pods.

A practical example

A team wants every call between its payment and ledger services to be encrypted and authenticated, and wants to send 5% of traffic to a new ledger version. Without a mesh, both services need TLS libraries, certificate rotation and custom routing code. With a mesh, the platform issues workload identities, enforces mTLS, and a routing rule shifts the traffic weight. Application code stays unchanged, and the team can revert by editing the rule.

Common mistakes

• Adopting a mesh to solve a problem that network policies or an ingress controller would already solve.
• Ignoring the resource overhead of sidecars and the extra latency hop they add.
• Rolling out strict mTLS everywhere at once instead of starting in a permissive mode and tightening per namespace.
• Treating the mesh as a security boundary on its own, without authorisation policies.
• Choosing a managed product without checking its lifecycle. AWS announced that it would discontinue AWS App Mesh on 30 September 2026, so new designs should not depend on it.

When to use it and when not to

A mesh is worth considering when you run many services, need uniform mTLS and traffic policy across teams, and have platform engineers able to operate it. It is usually not worth it for a handful of services, where application libraries, ingress rules and Kubernetes-native controls are simpler. See Istio for one specific implementation, and our Kubernetes consulting page for how we approach platform decisions.

See also

• Kubernetes
• Istio service mesh
• Distributed Tracing
• Network Policy
• Istio technology page