Why Service Mesh Is the Next Evolution of Microservices

1 The Pain of Traditional Microservices

Since Martin Fowler first introduced microservices in March 2014, frameworks like Spring Cloud and Dubbo have popularized them, but they still suffer from high technical barriers, insufficient multi‑language support, and strong code intrusion.

High technical threshold : Beyond service discovery, configuration centers, and authorization, teams must handle distributed tracing, circuit breaking, gray releases, failover, etc., demanding advanced expertise.

Insufficient multi‑language support : Large, fast‑growing teams often use heterogeneous tech stacks, yet no unified cross‑language microservice solution exists.

Strong code intrusion : Popular frameworks embed themselves into business code, making replacement costly and reducing adoption willingness.

These issues cause small teams to struggle and large enterprises to stall when adopting microservices.

2 Exploring an Alternative Path

One might consider a proxy approach at the load‑balancer layer (e.g., Nginx, Apache HTTP Server) to handle service calls and some governance concerns, but this introduces a centralized bottleneck and high operational complexity.

Is this the "Peach Garden"?

Service Mesh emerged as a solution. Since Linkerd’s public debut in September 2016, frameworks such as Linkerd, Envoy, Istio, NGINX Application Platform, and Conduit have proliferated, making the sidecar model the dominant trend of 2017.

3 Service Mesh

3.1 Definition

A service mesh is a dedicated infrastructure layer for handling service‑to‑service communication. It consists of a control plane and a data plane (service proxies act as “mesh”). – William Morgan, What’s a Service Mesh? And Why Do I Need One?

This definition highlights that a service mesh handles inter‑service communication, separating it from application code and addressing the multi‑language and intrusion problems of earlier microservice frameworks. Business teams can delegate governance complexities to the mesh.

Unlike the proxy model, the mesh uses a sidecar pattern: each service instance runs a parallel sidecar process on the same host, taking over all outbound network traffic, eliminating the centralized bottleneck and simplifying operations.

3.2 Evolution

The evolution of service mesh can be divided into three stages: (1) each service handles its own communication, (2) services use a unified library, and (3) services delegate all communication to sidecar processes, similar to how the TCP layer abstracts transport details from applications.

3.3 Timeline

Although the term "service mesh" was formally introduced in September 2016, similar ideas appeared earlier: Airbnb’s SmartStack (2013) focused on service discovery, and later Netflix’s Prana and OSP Local Proxy. After 2016, frameworks like Linkerd and Envoy gained traction, joined CNCF in 2017, leading to Istio’s rise and its 1.0 release in 2018, marking the transition to microservice 2.0.

4 Conclusion

This overview introduced the concept, benefits, and evolution of service mesh. Readers are invited to leave comments on the author’s issue board, and a future article will demonstrate how to set up an Istio‑based service mesh locally.

5 References

What’s a Service Mesh? And Why Do I Need One? – https://dzone.com/articles/whats-a-service-mesh-and-why-do-i-need-one

Pattern: Service Mesh – http://philcalcado.com/2017/08/03/pattern_service_mesh.html

Awesome Service Mesh – https://servicemesh.gitbooks.io/awesome-servicemesh/

Service Mesh: The Next Generation of Microservices – https://servicemesh.gitbooks.io/awesome-servicemesh/mesh/2017/service-mesh-next-generation-of-microservice/

Interpretation of 2017 Service Mesh: A Competitive Landscape – http://www.infoq.com/cn/articles/2017-service-mesh