Service mesh
A service mesh is an infrastructure layer for service-to-service communication, typically implemented as a sidecar proxy (Envoy, Linkerd-proxy) running alongside each service. The mesh handles concerns that would otherwise be repeated in each service: mutual TLS, retries, circuit breaking, load balancing, traffic routing, and observability — uniformly, without modifying application code.
The dominant meshes — Istio (2017), Linkerd (2016), Consul Connect — solve real problems in large microservice deployments but introduce their own complexity. Smaller teams often discover that the operational cost of the mesh exceeds the cost of solving the same problems in libraries or at the API gateway. The pragmatic adoption pattern: don't introduce a mesh until you have at least 20 microservices, traffic patterns that require per-service security policies (zero-trust), and an SRE function capable of operating it. For smaller environments, sidecar-free meshes (Cilium service mesh) and library-based approaches are increasingly viable alternatives.
Related terms
- Microservices
Microservices is an architectural style where a single application is composed of many small, independently-deployable services, each owning its own data and communicating over the network.
- Observability
Observability is the property of a system that lets engineers understand its internal state from external outputs — answering questions about how the system is behaving without modifying it.
- Circuit breaker
A circuit breaker is a pattern that monitors calls to a downstream service and 'trips' (stops calling) when failures exceed a threshold, returning a fallback or error immediately.