Service Mesh — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about service mesh technology.
The term "service mesh" was coined by Buoyant's William Morgan in 2017¶
While the concept of sidecar proxies existed before, William Morgan (CEO of Buoyant, creator of Linkerd) coined the term "service mesh" in a 2017 blog post. He defined it as "a dedicated infrastructure layer for handling service-to-service communication." The term caught on so quickly that within a year, every major tech company was either building or evaluating a service mesh.
Linkerd was the first service mesh but Istio got all the attention¶
Linkerd v1 (built in Scala, running on the JVM) was released in 2016, making it the first service mesh. Istio, backed by Google, IBM, and Lyft (via Envoy), launched in 2017 and captured the majority of industry attention due to its corporate backing and marketing. Buoyant responded by rewriting Linkerd in Rust (Linkerd2, 2018), creating a dramatically lighter-weight mesh. The Linkerd vs. Istio debate defined the service mesh space for years.
The sidecar proxy pattern doubles your container count overnight¶
A service mesh injects a sidecar proxy container alongside every application container. In a cluster with 500 pods, deploying a service mesh adds 500 more containers. These sidecars consume CPU and memory (Envoy typically uses 50-100 MB per instance), add ~1-3ms of latency per hop, and double the surface area for debugging. The resource overhead was the primary complaint about service meshes and drove the development of sidecar-less alternatives.
Envoy was not built for service mesh — it was Lyft's edge proxy¶
Matt Klein created Envoy at Lyft in 2016 as a replacement for their aging HAProxy-based edge proxy. Its L7 observability, dynamic configuration via xDS APIs, and HTTP/2 + gRPC support made it ideal for service-to-service communication. When Google and IBM needed a data plane for Istio, they adopted Envoy rather than building their own. Envoy's selection as Istio's data plane is what propelled it from "Lyft's proxy" to the foundation of the service mesh ecosystem.
mTLS everywhere was the service mesh's killer selling point¶
Before service meshes, encrypting service-to-service traffic required each application to manage its own TLS certificates, trust stores, and rotation — a task most teams simply skipped. Service meshes automated mutual TLS between all services transparently, with automatic certificate rotation handled by the control plane. This "flip a switch and get encryption everywhere" capability was often the primary justification for adopting a service mesh, ahead of observability or traffic management.
Istio's control plane went from microservices to a monolith (and nobody complained)¶
Istio originally had a microservices architecture for its control plane: Pilot (traffic management), Mixer (policy/telemetry), Citadel (certificates), and Galley (configuration). The complexity was overwhelming. In Istio 1.5 (2020), all components were merged into a single binary called "istiod." The move from microservices to monolith — in a project designed to manage microservices — was ironic but universally praised for simplifying operations.
The xDS protocol family became a standard beyond Envoy¶
Envoy's discovery service APIs — collectively called xDS (CDS, EDS, LDS, RDS, SDS, etc.) — define how the control plane pushes configuration to data plane proxies. These APIs became so widely adopted that they essentially became the standard interface for service mesh control planes. Projects like gRPC's xDS support allow applications to consume xDS configuration directly, enabling mesh-like behavior without a sidecar proxy.
Ambient mesh eliminates sidecars with per-node proxies¶
Istio's "ambient mesh" mode (announced 2022, GA in Istio 1.22, 2024) replaces per-pod sidecar proxies with per-node ztunnel (zero-trust tunnel) agents for L4 processing and optional waypoint proxies for L7 processing. This eliminates the memory and latency overhead of sidecars while preserving mTLS and observability. The approach represents the industry's acknowledgment that the sidecar model, while conceptually clean, was too expensive in practice.
eBPF-based meshes skip the proxy entirely for L3/L4¶
Cilium Service Mesh and similar eBPF-based approaches handle L3/L4 networking (mTLS, load balancing, network policy) directly in the Linux kernel via eBPF programs, without any userspace proxy. L7 processing (HTTP routing, retries) still requires a proxy, but the majority of mesh functions can operate at kernel speed. This approach provides service mesh features with significantly less overhead than sidecar-based architectures.
Most organizations that adopted service meshes didn't need one¶
A common criticism of the service mesh trend is that many organizations adopted service meshes for clusters with fewer than 50 services, where the operational complexity outweighed the benefits. Simple alternatives — application-level retries, a shared HTTP client library, and basic Kubernetes network policies — solve 80% of the problems for 20% of the complexity. The service mesh became a case study in resume-driven development and over-engineering.