Service mesh
A network layer that handles how microservices talk, so the code does not have to.
A service mesh is infrastructure that sits between the services of a microservices system and manages every call they make to each other. Instead of each team writing its own code for retries, timeouts, encryption and metrics, the mesh does it the same way for everyone, outside the application code.
The classic design puts a small proxy, a sidecar, next to every service instance, usually in the same Kubernetes pod. The service thinks it is calling another service directly, but the request actually goes through its sidecar, across the network, and into the other side's sidecar. Together, the sidecars are the data plane. A control plane configures them all centrally: which service may call which, how much traffic goes to a new version, which certificates to use. Newer designs drop the per-pod sidecar and share proxies per node to save resources.
What you get: mutual TLS between all services without touching the code, fine-grained traffic rules useful for canary releases, automatic retries, and uniform telemetry for observability. What it costs: another complex system to run, extra latency on every hop and more memory. It tends to pay off with dozens or hundreds of services, not with five. Istio and Linkerd are the best-known open-source meshes.
Keep in mind
- Moves retries, timeouts, encryption and metrics out of app code into the network layer.
- Data plane: proxies beside each service. Control plane: central configuration.
- Gives mutual TLS, traffic splitting and uniform telemetry.
- Adds latency and operational complexity; worth it at larger scale.
