Service Mesh
A service mesh moves service-to-service networking concerns into a data plane of proxies controlled by a central control plane, adding mTLS, retries, and telemetry without changing application code.
Definition
A service mesh is an infrastructure layer for service-to-service communication. A data plane of sidecar or node proxies handles mTLS, load balancing, retries, timeouts, and telemetry. A control plane configures those proxies and distributes identity and policy. Applications speak plain HTTP or gRPC to a local proxy and remain largely unaware of the mesh.
Context and scope
Meshes are used in Kubernetes and multi-service environments where consistent identity, traffic policy, and observability across languages are more valuable than the operational simplicity of direct calls.
Common misconceptions
- A mesh is required for microservices — many systems work well with libraries and a gateway
- A mesh makes applications secure automatically — it encrypts transport; authorization and input validation still belong to the application
- A mesh removes the need for timeouts in code — proxy policy helps, but the application still needs deadlines and cancellation
Anti-patterns
- Adopting a mesh without a clear problem it solves
- Allowing every service to call every other service because mTLS makes it look safe
- Ignoring the resource cost and failure modes of the proxies themselves
Related concepts
Authoritative source
Move networking out of every service
Without a mesh, every service implements its own TLS, retries, metrics, and traffic policy, often differently per language. A mesh moves those concerns into proxies next to each workload. The control plane defines identity and policy; the data plane enforces it consistently.
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
spec:
mtls:
mode: STRICTThe manifest is an Istio example. The principle is broader: transport identity and policy are configured centrally and enforced at the proxy, not hand-rolled in each application.
The mesh is infrastructure, not a security blanket
mTLS proves which workload is calling, but it does not decide whether that workload is allowed to call a specific endpoint. Authorization policy still needs to be defined. The mesh can enforce coarse network policy, but the application must enforce user-level authorization and validate inputs. A mesh also adds latency, memory, and a new failure domain; a broken control plane or proxy injection can affect every service.
Operate it deliberately
Roll out the mesh incrementally, start in permissive mTLS mode, observe before enforcing, and keep an escape path. Monitor proxy resource usage, certificate rotation, control-plane health, and configuration drift. Test what happens when the control plane is unavailable; the data plane should continue with the last known configuration.
When to use it
Use a mesh when consistent mTLS, traffic policy, and telemetry across many services and languages justify the operational cost. The advantage is uniform behavior without application changes; the drawback is complexity, resource overhead, and a new layer to debug. Compared to a library or an API gateway, a mesh covers east-west traffic but does not replace edge concerns or application-level authorization.