Event Mesh: The Architecture Layer for the Event-Driven Enterprise

Cesar Schneider
Jan 22 · 4 min read

What is a 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.

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.

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.

What Is a Service Mesh?

A service mesh is a configurable, low‑latency infrastructure layer designed to handle a high volume of network‑based interprocess communication among application infrastructure services using application programming interfaces (APIs). A service mesh ensures that communication among containerized and often ephemeral application infrastructure services is fast, reliable, and secure. The mesh provides critical capabilities including service discovery, load balancing, encryption, observability, traceability, authentication and authorization, and support for the circuit breaker pattern.

The service mesh is usually implemented by providing a proxy instance, called a sidecar, for each service instance. Sidecars handle interservice communications, monitoring, and security‑related concerns — indeed, anything that can be abstracted away from the individual services. This way, developers can handle development, support, and maintenance for the application code in the services; operations teams can maintain the service mesh and run the app.

A common use case for service mesh architecture is solving very demanding operational problems when using containers and microservices. Pioneers in microservices include companies like Lyft, Netflix, and Twitter, which each provide robust services to millions of users worldwide, hour in and hour out. For less demanding application needs, simpler architectures are likely to suffice.

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.

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 architectures. 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.

Cesar Schneider

Written by

Technology entrepreneur, software developer, hardware prototype maker, crypto investor, data science student, electronic music addicted.

The Startup

Medium's largest active publication, followed by +588K people. Follow to join our community.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade