Skip to main content
networking

Service Mesh

A service mesh is a dedicated infrastructure layer for service-to-service communication in microservices. Sidecar proxies (Envoy) handle mTLS, retries, circuit breaking, and observability transparently – without application code changes. Istio, Linkerd, and Consul Connect are the major implementations.

Definition

A service mesh decouples networking concerns from application code by injecting sidecar proxies alongside each service instance. Every network call passes through the local sidecar, which handles: mutual TLS (automatic encryption and identity verification between services), retries with backoff, circuit breaking (stop calling failing services), load balancing (client-side, with health awareness), rate limiting, and observability (distributed tracing, metrics, access logs). The control plane (Istio's istiod, Linkerd's control plane) configures all sidecars centrally – operators define policies (timeout=5s, retries=3, circuit-break-after=5-errors) without changing application code. Service meshes add latency (~1-3ms per hop from proxy overhead) and operational complexity (managing the mesh itself). They are justified when: you have 20+ services, need zero-trust mTLS everywhere, require consistent observability across polyglot services, or need traffic management (canary releases, traffic mirroring).

Examples

  • Istio: kubectl apply -f virtual-service-canary.yaml (90% v1, 10% v2)
  • Linkerd: linkerd inject deploy.yaml | kubectl apply -f - (adds sidecar)
  • Consul Connect: intentions define which services can communicate

Related Protocols

Related Terms