Loading...
A dedicated layer that handles how microservices talk: security, routing, and visibility.
Quick Definition
A service mesh is an infrastructure layer that manages communication between microservices, handling routing, security, observability, and traffic control. It offloads these concerns from application code, improving reliability and visibility, though it adds operational and resource overhead.
A service mesh is an infrastructure layer that manages communication between microservices. A small proxy sits beside each service instance, and together the proxies handle encryption, retries, timeouts, traffic routing, and detailed telemetry, taking those concerns out of application code entirely.
The value is uniformity: every service gets mutual TLS, consistent retry behavior, canary routing, and per-call observability without its developers writing any of it. The price is real: proxies consume CPU and memory beside every workload, add a little latency per hop, and the mesh itself is a sophisticated system someone must operate.
Example. A platform team adopts a mesh to meet an encryption-everywhere requirement across 80 services. The alternative, changing 80 codebases in five languages, would take quarters; the mesh delivers it in weeks, at the cost of roughly 8 percent additional compute for the proxy layer.
Adopt a mesh when its problems are actually yours, many services, strict security, complex traffic management, rather than by fashion. Istio and Linkerd lead the space. The Kubernetes Cost Management Guide accounts for the overhead honestly.
With a handful of services, almost certainly not. The case strengthens with service count, compliance demands, and traffic complexity.
Proxy CPU and memory beside every workload, typically 5 to 10 percent of cluster compute, plus meaningful operational attention.
Encryption where both sides authenticate each other. Meshes provide it automatically between all services, satisfying zero-trust requirements.