# Service mesh

> A network layer that handles how microservices talk, so the code does not have to.

- Level: Advanced
- Topics: Cloud
- URL: https://tidbit.legios.com.ar/service-mesh/
- In Spanish: [Service mesh](https://tidbit.legios.com.ar/es/service-mesh/)

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.

## An analogy

Like giving every office in a large company its own assistant who handles all the mail. People just say "send this to accounting"; the assistants handle sealed envelopes, retries when nobody answers and a log of everything, following rules set by one central office.

## 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.

## Go deeper

- [What is a service mesh? (Istio)](https://istio.io/latest/about/service-mesh/)
- [What is a service mesh? (Linkerd)](https://linkerd.io/what-is-a-service-mesh/)
- [Service mesh on Wikipedia](https://en.wikipedia.org/wiki/Service_mesh)

## Related terms

- [Microservices](https://tidbit.legios.com.ar/microservices/): Building one application as many small services that each do one job.
- [Encryption](https://tidbit.legios.com.ar/encryption/): Scrambling data so that only someone with the key can read it.
- [Proxy](https://tidbit.legios.com.ar/proxy/): A middleman computer that makes requests on someone else's behalf.
- [Kubernetes](https://tidbit.legios.com.ar/kubernetes/): The system that runs and babysits containers across many machines.
- [TLS certificate](https://tidbit.legios.com.ar/tls-certificate/): The ID card a website shows your browser to prove it is who it claims to be.
- [Canary release](https://tidbit.legios.com.ar/canary-release/): Releasing a new version to a small slice of users first, and widening only if it behaves.
- [Observability](https://tidbit.legios.com.ar/observability/): Being able to tell what a running system is doing, and why, from what it emits.
- [Bandwidth and latency](https://tidbit.legios.com.ar/bandwidth-and-latency/): How much data fits per second, and how long each trip takes. Two different things.