Evolving to Asynchronous Systems with Event-Driven Architecture

Real-time is no longer a “nice-to-have.” Sensors deployed in the Internet of Things (IoT) detect events that require a rapid response from another machine or sometimes from a human. The expectation that everything will interoperate with everything is no longer an assumption, it’s a requirement.

You can implement an Event-Driven Architecture (EDA) to achieve this. But that imposes the challenge of changing the way you think about systems.

EDA enables real-time notification and response for every event occurring within a system or within associated systems. Instead of waiting for a command or request to be issued, EDA is constantly vigilant, awaiting any of a large number of events to occur.

When events occur, a notification is sent to an event processor that takes appropriate action in response to the event. With an event router, multiple responses may be triggered. Also, multiple events happening at different times in different places may be combined to trigger response once they all achieve their necessary states.

The difference between a command and a triggering event is simple to visualize: You walk into a room equipped with a motion-detector light switch. The event of your entry is detected, the control for the light is notified, and the light turns on.

That’s an event. Alternatively, if you had to flip a switch to turn the light on, that’s a command.

Evolving to an Asynchronous, Reactive Model

The word reactive carries something of a negative connotation. Everyone wants to be proactive, right? But in the case of the evolution of application development, that’s exactly where we want to go.

Traditionally, developers were trained to think in procedures. Remote procedure calls, synchronous function calls, web services, APIs, and service-oriented architectures were the underpinnings of how applications were designed and built. All were synchronous, issuing a command complete with necessary data and metadata.

All functions were also tightly-coupled to each other, so modification was a substantial undertaking. Each function was aware of other functions, and each command expected a response. The fact that all code could easily be traced in the event of a malfunction was helpful, but synchronous systems were difficult to scale.

Conversely, EDA is loosely-coupled and asynchronous. Events may be sent directly to an event broker or mediator, depending upon the complexity of the response required. Where a command requires a response, an event may or may not trigger a response, or the event processor may need to wait for all involved events to occur before taking action.

None of the components of this architecture are aware of each other. Instead of sending a message and awaiting a response, all they do is send. The separation of every function makes it far easier to upgrade and continuously improve components of the system without having to take the entire thing down.

Getting Started with an EDA Implementation

Anyone implementing DevOps quickly learns that the most important task is to develop a DevOps culture within the organization. Participants need to change the way they approach the design and architecture of solutions.

They must also trade in the long-conditioned tendency to see everything as a sequence of requests, process, reply, confirm. There will be no more program calls, requests, declarations, or invocations. Instead, there will be events that require processing and responses that will often need to be produced.

As you shift paradigms from a request-driven architecture to an event-driven architecture, also shift your approach from one of orchestration to one more closely resembling choreography. The difference is simple. Orchestration tightly controls everything—all components and all interactions—and remains involved until each service is completed.

As you can imagine, this won’t scale readily as the orchestrator must await a response from each service it initiates before proceeding. Choreography provides patterns and routines that services follow, and it is expected they will do so without supervision or further instruction.

Tracking the flow of an EDA system is almost impossible since there is no set sequence of events. What happens in the system depends upon events taking place elsewhere in the system, or externally.

The same is true for planning an EDA solution. Anything that can occur within your organization must be seen as a digital event. Every operating process is a series of events. There are no recursive loops for confirming activities.

Planning for Implementation

The planning process concerns itself with identifying the events that may happen at any given point. It’s important to map the required responses to each under whatever combination of conditions they may occur.

Development

EDA requires decomposing your existing workflows into microservices. You also need to implement runtime fabric that supports the ability of these microservices to communicate in EDA’s preferred publish/subscribe (pub/sub) fashion, which is capable of distributing to many potential destinations.

Required runtime and design components:

• Event Broker: This most basic component for event routing in a pub/sub scenario provides low latency and guaranteed delivery. Decoupled applications and microservices converse through the event broker, preferably using open protocols and APIs.
• Event Mesh: A network of event brokers for routing events among applications deployed on-premises, in the cloud, or at the network edge.
• Event Portal: Similar to an API portal, the event portal provides a view into your event mesh, giving architects design tools that are GUI-based. Defined events, microservices and applications can also be designed in the portal.
• Event Taxonomy: This is the topic naming convention you design first and use consistently later. A good taxonomy supports event routing; it’s best to keep the conventions obvious and easily recognizable for developers.

An EDA Pilot to Play It Smart

For everyone involved, EDA is a dramatic change in the fundamental way they think about and approach application development, deployment, and operation. Success will depend upon winning buy-in from every group until the entire organization is familiar and comfortable.

For your pilot EDA project, choose something of moderate criticality from which the improvements will be readily observed and experienced. Moving from the comfortably confirmed communications world of synchronous systems to the highly-decoupled environment of EDA can feel like a “crossing the chasm” moment. It is strongly suggested that you seek out expert, experienced assistance as you embark on your journey.

Event-Driven Architecture is just one of the methods our product development teams use to drive your success. Contact 3Pillar Global today to learn how we can do it for you.

[adinserter name=”EDA Guide”]