Event-driven architectures and event meshes enable today’s modern distributed, cloud-native applications that are responsive to state changes.
Managing and using events can be a complex process with today’s cloud-native and highly distributed applications. Developers need a deeper understanding of how events are being used in applications, how to accommodate them, and the role of event-driven architectures and event meshes in using them.
RTInsights recently sat down with Hugo Guerrero, APIs & Integration Developer Advocate at Red Hat, to explore these topics and more. Here is a summary of our conversation.
What you need to know about events
RTInsights: What do developers need to know about events?
Guerrero: An event is any change or any action happening in your system. It is then shared with the rest of the elements and the components of your architecture. Most of the time, we tend to associate events with the notifications of an event. What we see from a change of state or action that has happened in our applications, in our systems, is the notification of the change of state or action. That’s what you are seeing, just a reflection of what happened. Most of the time, we deal with that notification because it’s the way to be aware that it’s happening.
Getting these notifications is a very powerful thing for a developer. If you get the notification that something happened in your system, you can react to that notification, and you can do something with that event that’s happening in your system. Either discard the notification and do nothing or use the notification to trigger any other part of my application or system to react to the event.
What event-enabling technologies are being used today?
RTInsights: What are some of the event enabling technologies used today?
Guerrero: Now that we have heard that events are something that’s happening in my system, and that what I’m interested in, is the notification of that event. We need a way to handle those notifications. A long time ago, when we wanted to share information between components in our systems, we used to have shared memory in our old type of design or applications that we’re running just one single type of system. However, today we’re moving towards the cloud, and we need a different type of mechanism to share that information. Things like messaging systems are becoming the solution to be able to share those notifications. We’re able to take ownership of a notification or event and then store it until somebody is ready to acknowledge the notification and be able to listen to it.
Most of the time, we tend to link events and messaging systems because that’s a very common way to have events propagated in the distributed system. But there are also other kinds of events that you can handle, for example, in memory. An event bus system is the one that is implemented using brokers or routers. In JavaScript, for example, they use this kind of approach to handle events in memory. There are also other solutions that are very specialized in handling access to memory and disk at the operating system level. An example is in trading, where you will need real-time communication. But most of the time, messaging systems are the ones that will help you to react to those events.
Developers need to have libraries or clients that connect to those systems. They need to either pull the messages or wait for them to be pushed from the server to an application. You can also have reactive programming. Depending on the model or on the language you’re using, you want to react to those messages, get them into an application, and then process them and consume them.
What is an event-driven architecture?
RTInsights: What is an event-driven architecture (EDA), and why is it needed?
Guerrero: An event-driven architecture is basically the description that I just mentioned. It’s the set components in your architecture that allows you to be able to create this message, grab notification of an event, and then use an event bus system, management system, or broker system to send this message with the notification and share that information with the rest of the system. Often when we are talking about an event-driven architecture, we’re talking about our producers of events. That includes any element in the application generating those events and sending them into the event bus.
With the event bus, we have two types of implementations. One is broker-centric, where you have a message broker or event broker receiving those messages, storing them, and then distributing them with the consumers or the listeners to those events.
Or you can have what we call the router type of approach, where you are just forwarding those events to the available consumers at that moment. But because they’re not stored, they are just delivered to those consumers that are available at the time of the propagation. The consumers of these elements can listen to the events, know what is happening, and then react to those events. Frequently, these consumers also become producers of events.
For example, consider the processes of an online purchase. You have an event generated in a database sent via an event bus to an application. The application consumes the event and does some processing when getting a new order. At the same time, this component of the architecture generates a new event to confirm that the payment was processed, shipping is ready, or the inventory has been updated and then sends back another event into the event bus.
Those are the elements of an event-driven architecture. And it is important to have all these design elements in their place because an event-driven architecture mirrors the real-world. You certainly won’t be waiting in line when ordering from a coffee shop until the person taking your order goes to the back, then prepares your coffee, and then gives it back to you. To be more efficient, we want to just go to one place, let somebody tell you the order, and then move away from the queue and wait for the mechanism where the person that took the order is sending the information to the barista that is the one that is actually preparing the coffee. Then you’re just called by your name, or by your order number, to be able to pick up the coffee.
What is an event mesh?
RTInsights: How does an event mesh enter the picture, and what does it do?
Guerrero: An event mesh is an extension for the event bus implementation. When we used to deal with events, it was in solutions that run in the memory and in the same, for example, Java virtual machine. We were just sharing information within threads, the same server, or within the operating system memory. But when we start to decompose applications and increase the distribution of our components and elements in the architecture, we have to have more bridges to get these events from one place to another. First, we needed to get out of the server, and we had to go into the cluster. We had to share this information within a group of machines within a single data center.
But now there is the cloud. We need to deal with deployments that are not just within one data center, but within different availability zones and different regions. With the approach around multi-cloud and hybrid cloud, we also need to spread these types of events within multiple clouds and hybrid types of deployments. And this is where we need to start to create this event fabric that allows us to have an abstraction layer on top of the implementation details. At the application level, the fabric allows us to communicate and share these events seamlessly between any type of deployment. The event mesh is this idea of sharing the events within the same cluster and business domain, but at the same time, letting us push that event into the extended network of components deployed in different clouds. The event mesh lets us share an event using network replication mechanisms to send that event into other deployments.
In this way, we can connect all these different elements into this fabric, and we’re going to be able to send and share that information. When you just had to share events and brokers within one domain, the implementation could be based on Apache Kafka. But then, when you try to share that information with another cluster, you will certainly need to do replication or use other proxies that allow you to connect to different clusters. Suppose you want to replicate that message into a system that perhaps uses a traditional store and forward broker, and that broker lives in your own data center. In that case, you need to push that message or that event into a traditional virtual machine application that is just listening to AMQP protocols.
Such a fabric that allows you to share an event that is propagated from data running in your own data center to a serverless application running on the cloud is the concept of the event mesh that we have been working on for a while here in Red Hat. Abstracting at that level, you can get the implementation that best suits your event consumption patterns. At the same time, from the application perspective, you can share, consume the event, and produce events in a very seamless way.
