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.
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.
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:
There are three defining characteristics of an event mesh. An event mesh is:
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.
In short, an event mesh supports use cases like:
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.
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/use-cases/event-mesh/
Shawn McAllister is responsible for the strategy and delivery of the Solace PubSub+ Event Streaming and Management Platform. He leads a team of incredibly talented engineers and architects in this endeavor.
McAllister has worked with many of our clients to help them adopt an event-driven architecture and to learn first-hand their needs as input to the innovation built into the PubSub+ Platform. He has participated in the definition of various OASIS messaging protocol standards, including MQTT 3.1.1, MQTT 5.0, and AMQP1.0.
Before joining Solace, McAllister led software, hardware, and test engineering teams at Newbridge Networks (later Alcatel Canada), where he was responsible for developing features on ATM and Ethernet switches as well as the 7750 Multiservice IP Router.
McAllister holds a Bachelor of Mathematics from the University of Waterloo, with majors in both Computer Science and Combinatorics/Optimization.[position] => Chief Technology Officer & Chief Product Officer [url] => https://solace.com/blog/author/shawnmcallister/ ) )