Service Mesh

A SERVICE MESH is service discovery + load balancing + security + observability, often via a SIDECAR PROXY pattern.

┌────────────┐         ┌────────────┐
│ Service A  │         │ Service B  │
└─────┬──────┘         └─────┬──────┘
      │ localhost            │ localhost
      ▼                      ▼
┌────────────┐         ┌────────────┐
│  Envoy     │  mTLS   │  Envoy     │
│ (sidecar)  │ ─────► │ (sidecar)   │
└────────────┘         └────────────┘
      ▲                      ▲
      │ control plane        │
      ▼                      ▼
┌─────────────────────────────────┐
│      Istiod (control plane)      │
│  service discovery, policies     │
└─────────────────────────────────┘

Every service has a sidecar (Envoy proxy). Sidecars handle:

• Service discovery (from control plane)
• mTLS encryption (transparent to app)
• Retries, timeouts, circuit breakers
• Distributed tracing (Jaeger, Zipkin)
• Metrics (Prometheus)

Application code is unaware. Just connects to localhost; sidecar handles the rest.

Major players:

• Istio (Google + IBM): comprehensive; complex
• Linkerd: simpler; Rust-based proxy
• Consul Connect: built into Consul
• AWS App Mesh: managed
• Cilium Service Mesh: eBPF-based; no sidecar

Trade-offs: sidecars add latency (~1ms per hop) and resource cost (~50MB RAM per sidecar). For a 1000-pod cluster, that's significant.

eBPF-based meshes (Cilium) achieve sidecar-free operation for some features. The future likely combines both.