Supporting Asynchronous, Event-Driven Interactions with an Event Mesh

Service Mesh is being embraced as an infrastructure layer for microservices that makes communication flexible, reliable and fast. It’s promoted by industry giants such as Google, Microsoft, IBM, Red Hat and Pivotal, and it’s being rolled out with Kubernetes, OpenShift and Pivotal Container Service (PKS).

But while service mesh works well to support synchronous RESTful and general request-reply interactions, it doesn’t support asynchronous, event-driven interactions, nor is it well suited for connecting cloud-native microservices with legacy applications, or enabling IoT.

Modern enterprises are embracing event-driven architecture as part of their digital transformation, and every event-driven enterprise will need a central nervous system to quickly, reliably and securely move events from where they are occurring to where they need to go.

The central nervous system enterprises need can be thought of as an event mesh – a new layer in your architecture.

Event mesh complements service mesh, completing the application connectivity layer to provide the full set of inter-application communication patterns enterprises need to realize their digital transformation ambitions.

What is ‘Event Mesh’?

An event mesh is to your event-driven applications what a service mesh is to your RESTful applications: an architecture layer that enables events from one application to be dynamically routed and received by any other application, no matter where these applications are deployed (no cloud, private cloud, or public cloud). An event mesh is created and enabled by a network of interconnected event brokers.

Figure 1-This diagram shows where an event mesh fits in an application stack relative to other technologies such as service mesh.

Event Mesh vs. Service Mesh

Event mesh complements service mesh. Event mesh and service mesh are similar in that they enable better communication between applications and allow applications to focus more on business logic by putting certain functions into a layer between the network and the application. However, there are a few important distinctions of an event mesh:

• Service mesh connects microservices in cloud environments such as Kubernetes, Amazon ECS, Google Kubernetes Engine, IBM Cloud and Alibaba.
• Event mesh connects not only microservices (containerized or otherwise), but also legacy applications, cloud-native services, and the wide variety of devices and data sources/sinks that can operate in cloud and non-cloud environments. An event mesh can connect any event source to any event handler no matter where they are deployed.

Characteristics of Event Mesh

There are three defining characteristics of an event mesh. An event mesh is:

1. Made up of interconnected event brokers
2. Environment-agnostic
3. Dynamic

The fact that an event mesh is created and enabled by a network of event brokers (1) means it is inherently event-driven.

“I believe events will become the life-blood of the modern enterprise.”

By environment-agnostic (2), I mean that the mesh can be deployed in any public cloud, private cloud, PaaS, or non-cloud environment, and it will operate in a uniform way in all environments.

The dynamic character (3) of an event mesh is probably its most important attribute. By this I’m referring to its ability to dynamically learn which events are to be routed to which consumer applications and then to route these events in real-time as the events occur, no matter where the producer and consumer are attached to the mesh, and without needing to configure event routing. The event mesh takes care of this, not the developer.

Why do enterprises need an event mesh?

In short, an event mesh supports use cases like:

• Connecting and choreographing microservices
• Pushing events from on-premises to cloud applications or services (hybrid cloud)
• Enabling “data as a service” across LOBs
• Enabling IoT connectivity to back-end systems

Here’s the longer answer:

An event mesh gives enterprises the ability to support event-driven architectures, from the smallest of microservices deployments, to extending applications to the hybrid cloud in a governed, robust, secure and well-architected manner. It provides the ability to integrate legacy applications, data stores, modern microservices, SaaS, IoT and mobile devices — dynamically and all in real-time. An event mesh gives application developers and architects a foundation on which to build and deploy distributed event-driven applications, wherever they need to be built and deployed.

Conclusion

The event mesh concept is meant to enable and support enterprise digital transformation. In 2018, enterprises are turning toward if not fully embracing event-driven architecture. But in my experience, many are doing so for select use cases and often with a piecemeal approach rather than a clear vision for enterprise-wide event distribution.

I believe events will become the life-blood of the modern enterprise. For this to happen, they will need to flow freely and easily across every environment and component of the digital enterprise, which is increasingly becoming distributed.

Event mesh is the architectural layer that will enable this.

Find out how Solace enables an event mesh with PubSub+, our advanced event brokers: https://solace.com/solutions/initiative/event-mesh/