The concept of using a “service mesh” to manage service-to-service communications within a cluster first began being talked about in 2016, guided partly by the hype-driven adoption of microservices-based architectures, and also the acceptance of Kubernetes as the de facto way to orchestrate containers.
Microservices brought many benefits, such as the ability to construct a system of “polyglot” services that used languages suitable for each task. However, this architectural trend also introduced challenges inherent within distributed systems that transfer data over an unreliable and heterogeneous network, such as the difficulty of implementing cross-cutting communication concerns that were previously included within the monolithic codebase, like security, reliability, and observability. The initial microservices maxim of creating “smart endpoints and dumb pipes” has now evolved, and service meshes are vying to put just enough smarts back into the pipes.
To co-opt William Gibson’s catchphrase, the future of service meshes is already here -- it’s just not evenly distributed. The aim of this guide is to remove some of the confusion and to help choose if, when, and how to deploy a service mesh. We welcome any feedback, and please do follow future developments in the service mesh space by following the topic on InfoQ.
Free download
The InfoQ eMag - Service Mesh: Past, Present, and Future includes:
- Linkerd v2: How Lessons from Production Adoption Resulted in a Rewrite of the Service Mesh – Linkerd 2.0 introduced a substantial rewrite of the widely adopted service mesh, using a split between Go and Rust. In this article, we discuss the lessons learned in the "cauldron of production adoption", and how those lessons became the basis of Linkerd 2.x’s philosophy, design, and implementation.
- API Gateways and Service Meshes: Opening the Door to Application Modernisation – Modernizing applications by decoupling them from the underlying infrastructure on which they are running can enable innovation, reduce costs, and improve security. An API Gateway can decouple applications from external consumers, and a service mesh decouples applications from internal consumers.
- To Multicluster, or Not to Multicluster: Inter-Cluster Communication Using a Service Mesh – Communication within Kubernetes clusters is a solved issue, but communication across clusters requires more design and operational overhead. Before deciding on whether to implement multicluster support, you should understand your communication use case.
- Application Integration for Microservices Architectures: A Service Mesh Is Not an ESB – A service mesh is only meant to be used as infrastructure for communication between services, and developers should not be building any business logic inside the service mesh. Other frameworks and libraries can be used to implement cloud-native enterprise application integration patterns.
- The Potential for Using a Service Mesh for Event-Driven Messaging – In this article, we discuss one of the most challenging and unexplored areas in service mesh architecture; supporting event-driven messaging. There are two main architectural patterns that we discuss here: the protocol proxy sidecar, and the HTTP bridge sidecar. Regardless of the pattern that is used, the sidecar can facilitate features such as observability, throttling, tracing, etc.
InfoQ eMags are professionally designed, downloadable collections of popular InfoQ content - articles, interviews, presentations, and research - covering the latest software development technologies, trends, and topics.