Why Your Microservices Strategy Needs Service Mesh and Event Mesh

Since announcing our intention to enable a then-new kind of application infrastructure known as event mesh in 2018, we’ve been helping people understand how event mesh differs from service mesh, how the two are similar, and why you need both for microservices. I myself introduced the well-known service mesh to its younger sibling in a blog post that holds up pretty well even today.

My former colleague, Heinz Schaffner, has taken things to another level altogether with what I believe is the definitive explanation about service mesh and event mesh, and how using the two together is the best strategy for your microservices architecture. His new whitepaper was written from his experience working directly with customers and fielding questions passed along by our systems engineering and services teams. In Comparing and Contrasting Service Mesh and Event Mesh, Heinz has answered a litany of questions that technologists have asked in trying to understand how service mesh and event mesh work at a technical level, how to make best use of each, and how they can both be used for enhancing your microservices strategy.

I’ll give you a brief overview below.

Service Mesh and Event Mesh for Microservices; What You’ll Learn

Service mesh and event mesh were both born of the need to improve agility by decomposing monolithic applications into discrete functions called microservices. The distributed nature of these applications meant that microservices now had to deal with the problems of network communication (vs method calls), they needed multiple types of communication patterns (request/reply, 1-to-many), multiple communication qualities of service, a need to support hybrid cloud communications and more. These are the motivations for both service mesh and event mesh. This paper will help you understand how these two “mesh” technologies came to be, the role each plays, and how you can throw the powerful one-two punch they represent.

In this paper Heinz will help you understand how the control and data planes of a service mesh work, and why they don’t meet the needs of event-driven microservices. You’ll then learn how event meshes came to be, how they work, and how to use them in concert with service meshes for the most powerful, flexible and scalable microservices-based system possible.

This diagram illustrates how service mesh and event mesh build upon your network and Kubernetes infrastructure to enable communications between request/reply microservices, event-driven microservices, and hybrid microservices that make use of both request/reply and event-driven communications.

Simply put, a service mesh provides connection-level routing and traffic management for synchronous request/reply communications through sidecar injection into Kubernetes Pods; effectively “hijacking” and overriding connection requests from the microservices. Event meshes, on the other hand, handle the asynchronous event-driven routing of information through event brokers. This enables more immediate delivery and makes it so consumers don’t have to be available when the event is produced. Another key difference is that unlike a service mesh, an event mesh can enable integration across both Kubernetes and non-Kubernetes environments.

Example of Using Both Service Mesh and Event Mesh for Microservices

Below is a simple example that shows how Microservice A, driven by synchronous interactions, can inform other microservices of an event having occurred (e.g. “account opened”) by sending an event to an event broker. Other microservices (C, D and E) can perform actions as a result of this event.

Conclusion

If you’re responsible for architecting systems based on microservices, or developing microservices themselves, I suggest you give Heinz’s paper a read and if you have any questions, feel free to ask away in our Developer community.