Service mesh
A dedicated infrastructure layer for service-to-service communication, providing mTLS, traffic control, observability, and resilience via sidecars. Istio and Linkerd are examples. Adds capabilities without app code changes.
- Large microservice estates needing uniform security/observability/routing.
- Zero-trust networks.
- Small service counts (overhead not justified).
- Teams without mesh expertise.
Definition
A service mesh intercepts all east-west traffic via sidecar proxies (Envoy) and manages it via a control plane. It provides mTLS, retries, timeouts, circuit breaking, traffic splitting (canaries), and metrics/tracing uniformly.
Why it exists
Service-to-service concerns (security, resilience, observability, routing) are needed everywhere and shouldn't be reimplemented per app/language. A mesh centralizes them, decoupling them from app code.
How it works
Sidecar proxies sit beside each service; all traffic flows through them. The control plane configures policies, certificates, and routes. mTLS is automatic; traffic shifts enable canaries; telemetry is uniform.
Scaling limits
Sidecar overhead (CPU/memory/latency) per pod. Control plane complexity. Debugging through an extra proxy layer is harder. Misconfiguration affects all traffic.
Cost shape
Per-pod sidecar resources + control plane + ops. Blow-ups: sidecar overhead at scale and the operational cost of running the mesh.
Alternatives
- In-app libraries — No proxy overhead, but language-specific and duplicative.
- API gateway only — Handles north-south, not east-west.
Failure modes
- Sidecar latency/overhead.
- Control plane outages.
- Hard-to-debug routing through proxies.