Service Mesh

A service mesh is an infrastructure layer that handles service-to-service communication for a microservices application: routing, retries, timeouts, mTLS encryption, authorization, traffic shifting, and observability. The mesh moves these cross-cutting concerns out of each service into a dedicated layer, typically implemented as a sidecar proxy or a kernel module per pod.

How it works

Most service meshes follow the same architecture: a data plane of proxies (Envoy is the dominant choice) that intercepts every inbound and outbound request, and a control plane that configures the proxies based on declarative policy. Services communicate as before; the mesh transparently adds mTLS, retries, traffic splits, and emits telemetry.

What a mesh typically provides

• mTLS. Mutual TLS between every pair of services, with automatic certificate rotation.
• Traffic management. Weighted routing, canary deployments, fault injection, retries with backoff, circuit breaking.
• Authorization. Per-service or per-path policies, often expressed as Kubernetes CRDs.
• Observability. Uniform metrics, traces, and access logs across all services without changing application code.

Common meshes

• Istio. Feature-rich, Envoy-based, the most widely deployed.
• Linkerd. Ultra-light, Rust-based proxy, simpler operational model.
• Cilium Service Mesh. eBPF-based, sidecarless, integrates with Cilium CNI.
• Consul Connect. HashiCorp's mesh, works beyond Kubernetes.
• AWS App Mesh, GCP Anthos Service Mesh, Azure Service Mesh. Managed flavours.