Moving the Complexity
When organizations move from a single, giant monolithic application to dozens or hundreds of small microservices, they solve one problem (development speed) but create a new one: network complexity.
In a monolith, component A calls component B via a simple in-memory function call. There is no network involved — no packets, no timeouts, no encryption. In microservices, service A must make a real network request to reach service B, crossing a cluster that may span multiple physical machines.
Suddenly, developers have to worry about things that have nothing to do with business logic:
- Reliability: What if service B is temporarily down? Do I retry? How many times? With exponential backoff?
- Security: Is the traffic between A and B encrypted? How does B know that A is actually allowed to call it, and not some rogue process?
- Observability: Why is this request slow? Is it A's fault, the network's fault, or B's fault? Which hop is the bottleneck?
The naive solution is to solve each of these problems inside every service — write retry logic in Go for one service, in Python for another, in Java for a third. This creates a maintenance nightmare: every team reinvents the same wheel, and a bug in the retry logic must be fixed in a dozen codebases simultaneously.
A Service Mesh is a dedicated infrastructure layer that handles all of this service-to-service communication logic, extracting it completely out of your application code. Developers write business features; the mesh handles the network. This separation of concerns is the core value proposition.