Service Mesh. Concepts

Your microservices architecture has 30 services. Every service needs:

• Mutual TLS (encrypted service-to-service communication)
• Retries with exponential backoff (resilience)
• Circuit breakers (fault tolerance)
• Load balancing (traffic distribution)
• Distributed tracing (observability)
• Rate limiting (protection)
• Canary deployments (safe rollouts)

You could implement these in every service. But that means every service, whether written in Go, Python, Java, or Node.js, needs the same networking logic. Every team maintains the same retry policies, the same TLS configuration, the same circuit breaker thresholds. When you need to change the retry policy, you update 30 services.

Netflix tried the library approach first. They built Ribbon (load balancing), Hystrix (circuit breaking), and Eureka (service discovery) as Java libraries. It worked, but only for Java services. When teams started writing Go and Python services, they needed to reimplement everything. Maintaining parity across three language implementations became a full-time job.

A service mesh moves all of this into the infrastructure layer. Your services handle business logic. The mesh handles networking. Your Go service and your Python service automatically get mTLS, retries, tracing, and load balancing without a single line of networking code.

A service mesh has two components:

Data Plane: the sidecar proxies. Every service instance gets a lightweight proxy (typically Envoy) deployed alongside it. All traffic in and out of the service flows through this proxy. The proxy handles encryption, retries, circuit breaking, load balancing, and telemetry collection, transparently.

Control Plane: the brain. A centralized component that configures all the proxies. You tell the control plane "enable mTLS between all services" or "route 5% of traffic to the canary version" and it pushes this configuration to every proxy in the mesh.