An Overview of Service Mesh: Addressing the Limitations of Traditional Microservices

1 The Pain of Microservices

Since the introduction of microservices in 2014, frameworks like Spring Cloud and Dubbo have become mainstream, yet they suffer from high technical barriers, insufficient multi‑language support, and strong code intrusion, making adoption difficult for both small and large teams.

High technical threshold: beyond service discovery, configuration, and authorization, teams must handle distributed tracing, circuit breaking, gray releases, failover, etc.

Insufficient multi‑language support: no unified cross‑language stack for heterogeneous teams.

Strong code intrusion: frameworks embed themselves in business code, raising replacement costs.

These issues cause small teams to give up and large companies to stall.

2 An Alternative Path

Using a proxy at the load‑balancer layer (e.g., Nginx, Apache) can handle service calls and some governance, but it introduces a centralized bottleneck and high operational complexity.

Is this the “Peach Garden”?

Service Mesh emerged as a solution, with projects such as Linkerd, Envoy, Istio, NGINX Application Platform, and Conduit appearing rapidly after Linkerd’s public release in September 2016.

3 Service Mesh

3.1 Definition

A service mesh is a dedicated infrastructure layer for handling service‑to‑service communication. Consists of a control plane and data plane (service proxies act as “mesh”). – William Morgan

The definition highlights that a service mesh handles inter‑service communication as an independent infrastructure layer, solving the multi‑language and code‑intrusion problems of traditional microservice frameworks. Its sidecar model deploys a proxy alongside each service instance, eliminating the central proxy bottleneck and simplifying operations.

3.2 Evolution

The evolution of service mesh can be divided into three stages: (1) each service manages its own communication, (2) services share a common library, (3) communication is fully delegated to sidecar proxies, similar to how the TCP layer abstracts transport details from the application layer.

3.3 Timeline

Although the term “service mesh” was coined in 2016, earlier efforts such as Airbnb’s SmartStack (2013), Netflix’s Prana, and Vipshop’s OSP Local Proxy laid groundwork. After 2016, Linkerd and Envoy gained traction, joined CNCF in 2017, and led to the creation of Istio, whose 1.0 release in 2018 marked the transition to microservice 2.0.

4 Summary

The article provides a concise overview of service mesh, its motivations, architecture, evolution, and key projects, and invites readers to discuss further or follow upcoming tutorials on building an Istio‑based mesh.

5 References

What’s a Service Mesh? And Why Do I Need One?

Pattern: Service Mesh

Awesome Service Mesh

Service Mesh: Next‑Generation Microservices

Interpretation of 2017 Service Mesh: A Competitive Landscape