Lyft built Envoy and open-sourced it in 2016 to move networking concerns out of application services. What problem did that actually solve, and for which organisations does a service mesh fail to pay for itself?

The situation they were in

A growing microservice estate written in several languages, where retries, timeouts, circuit breaking, load balancing and request-level telemetry were implemented in per-language client libraries. That arrangement has one property that gets worse with time: every capability must be built and maintained N times, and every fix reaches services only as fast as N libraries can be upgraded and redeployed. Consistent observability is the part that suffers first, because a trace is only as complete as the least-updated library in the path.

What they chose

A sidecar proxy alongside every service instance, carrying all inbound and outbound traffic. Networking behaviour moves into the proxy, which is one program in one language, configured centrally. Envoy's design added the property that made it adoptable: a dynamic configuration API, so behaviour could change without restarting the proxy or the application.

The uniform telemetry is the benefit teams underrate. Every hop produces the same metrics in the same format regardless of the service's language, so latency, error rate and retry rate across the estate become comparable for the first time.

Why it fit their constraints

Polyglot estate, many services, a platform team able to own a proxy fleet, and a strong need for consistent traffic control during rapid growth. Each of those is a condition, not a description of every company.

What it costs

• A second process per instance: CPU and memory per pod, plus one to several milliseconds of added latency per hop, which compounds on a deep call chain.
• A control plane to run, which becomes a tier-zero dependency. When it is unavailable, existing routes usually keep working and changes do not propagate, so the failure is silent until someone needs a change.
• Certificates. Mesh mTLS means certificate rotation for every workload, and expiry is the classic mesh outage: nothing is wrong with any service, and all traffic stops.
• Debugging changes shape. A connection failure is now potentially in the application, the sidecar, the control plane's view of endpoints, or the policy layer. Teams need to learn the proxy's own telemetry to keep diagnosing at the same speed.

When it is the wrong answer

Twelve services in one language with a decent client library do not need a mesh. The library can hold retries, timeouts and tracing, and it reaches every service because there is only one language to update. The mesh's core benefit — uniformity across implementations you cannot change together — has nothing to act on.

The decision rule: count the languages, count the services, and ask who runs the control plane. Two or more languages with tens of services and a platform team is where a mesh starts paying. One language, or no team to own it, and the operational bill arrives every week while the benefit stays theoretical. An intermediate position that works well: adopt the proxy without the mesh, as a shared gateway or per-host proxy, and get most of the telemetry for a fraction of the operational surface.