Event-Driven Architecture

Architectures adapt to advances in technology. From the very beginning of the Information Age, architectures have been request-driven, that is, a user makes a request and the system responds.

Most recently we’ve seen computing systems go beyond person-to-machine (P2M) interaction to extensive machine-to-machine (M2M) interaction. In the age of the Internet of Things (IoT) sensors communicate events back to a central system that may instruct messages to be sent, lights or other indicators to go on or off, bridges to be raised, streetlamps to light streets, and much more.

As M2M becomes a larger proportion of online interactions than P2M it becomes necessary to accommodate the idea that events will be the triggers of action rather than requests.

This has given rise to the development of Event-Driven-Architecture (EDA), an advanced structure for perceiving the occurrence of an event, interpreting and processing that event, determine what action or actions must be taken, and triggering those actions.

Already we’ve seen EDA driving real time analytics, fraud detection, sentiment analysis, business process monitoring, real-time personalization of user experience, healthcare monitoring, Medicaid Management Information Systems, IoT applications, trading floors, online shipping, and much more.

Interoperability is the core enabler of IoT, Smart Home, Industrial Internet of Things (IIoT) and automation. Systems created by different manufacturers and software developers must be able to receive notification of specific events from each other and be able to reliably interpret and evaluate those events to determine what response is required. Then they must trigger that response without operator intervention. EDA was developed to serve that need.

EDA is also designed to deliver excellent resilience and fault-tolerance. It is highly granular and loosely coupled similar to the structure of microservices in containers that has recently overcome monolithic development limitations.

This content series defines EDA, highlighting the advantages and challenges, suggesting best use cases, and describing the internal structure in general terms with the goal of enabling better decision-making regarding deployment. Not only will you be able to better determine where to apply EDA, but also how.

Chapter 1: What is Event Driven Architecture?

Event Driven Architecture on Blue Background

In the beginning people communicated with people. Much more recently people communicate with machines. Today, and with increasing presence going forward machines will communicate with other machines (M2M).

Technology, and the software that drives it, must adapt to facilitate M2M. Since there’s no person issuing commands or clicking links to make requests, the machines will need to respond to events occuring in the real world around them. The exploding growth of the Internet of Things (IoT) provides a wealth of sensors watching and waiting for events, as well as switches ready to impact their surroundings. Between them there’s a need for a whole new approach to software, a whole new systems architecture.

Event-Driven Architecture (EDA) is that new approach. In this first chapter we introduce the fundamental characteristics of EDA, when and where it is best applied, and how it interacts well with the processing of microservices in containers. Read more.

 

Chapter 2: Components of Event Driven Architecture

Blue Lights on Black Background Abstract of Event Driven Architecture

EDA is highly structured and well-defined. At the same time EDA is very loosely coupled and highly distributed, making it even more resilient. Events are captured, submitted to a selection of topologies depending upon the nature of the event and then sent for processing which varies somewhat for simple, complex, streaming, and other types of events. In all cases, the failure of one component does not occasion the failure of the entire system. Buffers hold onto events captured until the faulty component can be remedied.

The layers of this architecture assure a smooth consistent flow and each is examined separately in this chapter, beginning with an exhaustive list of the various components active within, along with helpful descriptions of each. Before you can tour the road, you need to know the signposts and milestones. Read more.

 

Chapter 3: Event Driven Architecture Topologies

Hand Drawn Sketch of Event Driven Architecture

Now that we are aware of the various components its time to examine the topologies available to move and process events through them. As one might expect there’s a topology for simple events, and another for complex, multi-step responses to events.
In this chapter you’ll begin to see how events flow from capture through processing to triggered response or responses. This is the first step toward actual event processing. Read more.

 

Chapter 4: Event Processing Approaches in Event Driven Architecture

People Deciding Between Many Approaches of Event Driven Architecture

In the Internet of Things filled with hundreds of thousands, perhaps millions of devices there are going to be many different types of events to capture each of which will, in turn, require different kinds of processing. EDA breaks this down into just a handful of processing types which will enable the appropriate response to each event in a timely manner. Here’s how events are assigned to the appropriate processors and accessed by the intended consumers! Read more.

 

Chapter 5: Advantages of Event Driven Architecture

Abstact Image Depicting Event Streaming

By now you’ve developed a better general sense of what EDA enables, and how it does so. Next we examine how this translates into valuable advantages in the real world. Given that the entire ability of the Internet of Things, and many other things, to function is very much dependent upon each device’s degree of interoperability with other devices, this makes EDA a vital component in an increasingly automated world filled with increasing diverse devices from many different manufacturers. Here’s how EDA delivers us to a world in which everything must be delivered upon demand! Read more.

 

Chapter 6: When to Use Event Driven Architectures

Person Deciding When to Use Event Driven Architecture

As with almost all technology implementations, the decision to use a specific architecture like EDA is very much dependent upon the desired outcomes from the solutions. More and more of today’s applications, especially those that facilitate communication between various devices, are best served in asynchronous fashion with components loosely coupled with others. This promotes both resilience and ready scalability. Especially as artificial intelligence is embedded into more and more software, EDA powerfully facilitates efficiencies from the systems they run on. Read more.

 

Chapter 7: Microservices and EDA

Abstract Representation of Event Driven Architecture and Microservices

In many ways EDA is the product of the same thinking that led us away from monolithic programming in which everything is contained in one monolithic block of code, to microservices in containers, in which every component stands alone, separate, and loosely coupled from others. In the age of the monolith, a failure of anything caused the failure of the entire system resulting in excessive downtime. The new world of microservices assures continuous operation. When a component fails, it is simply destroyed and re-instantiated. Highly resilient with the promise of new dimensions of availability.

This consistency of architecture paves the way to highly responsive cloud-native applications built to traverse the entire internet without losing functionality. This is where EDA leads you into an environment of continuous improvement through continuous deployment (CI/CD). Read more.

 

Chapter 8: Disadvantages of Event Driven Architecture

Arrow Crashing into the Ground Representing Disadvantages of Event Driven Architecture

While superior characteristics like loose coupling provide significant value, they also create disadvantages that must be carefully considered when transitioning workloads to EDA. The essential nature of EDA has it forming connections between highly diverse systems. Anticipating when and how issues may arise, and documenting guidance to respond to those issues becomes a tremendous and burdensome problem, but the payoff is the kind of interoperability needed for tomorrow’s systems.

Troubleshooting also takes on new dimensions of difficulty. How do you trace logic paths that cross from system to system? Here’s food for thought on how to prepare for that. Read more.

 

Chapter #9: Overcoming Challenges of Event Driven Architecture

Person on Top of Mountain Overcoming a Challenge

Nothing great ever comes for free. EDA offers tremendous advantages in its loosely-coupled, asynchronous and highly granular nature, but there will be challenges to confront and defeat. The adaptation to such a widely differing approach from what most developers are used to is just the first challenge. Adding new skills, improving old ones, are part of the price to entry.
You’re entering a world in which much of what happens depends upon interactions external to the systems involved, and the mere fact that there are multiple systems involved is in itself a major challenge.

You’ll need to become adept at anticipating the unknown and seeing the unforeseen. Since the components involved are not all on the same systems there’s no roadmap to follow. You’ll often find it difficult to trace down errors when they occur. The best hedge against this will be careful, comprehensive governance and documentation. EDA could just as easily signify Extremely Disciplined Architecture. Read more.

 

Chapter 10: Evolving Your System by Implementing EDA

People Putting Together Puzzle Representing an EDA Implementation

Implementing EDA represents far more than simply adopting a new architecture. It requires making a paradigm shift from a history of request-driven to a brand new event-driven practice. This is no mean feat. You’ll find yourself reminding yourself to think differently.
In this new, evolved environment everything is orchestrated by software. Your ability to automate more activities within your system suddenly seems easy by comparison. You’ll sleep better at night knowing the likelihood of catastrophic system failure is all but eliminated by the loosely-coupled, highly distributed nature of the architecture. The term “real-time” will suddenly take on new meaning.

Ultimately, you’re removing people from the fundamental operations as much as possible which frees them to focus on higher-level, higher-value activities. Thus you’re not only evolving your systems, you’re evolving your entire organization. Read More.

 

Chapter 11: Leveraging a Partner for EDA Success

Tiempo Helping a Client Achieve Success with Event Driven Architecture

Setting about making a transition like implementing EDA the first tools you’ll need are expertise and experience. One of your objectives should be to enjoy the shortest possible time-to-value from this endeavor. If you try to learn on the fly time will go by faster than you’ll realize.

You may consider hiring someone with EDA background, or training an existing staff member, but both are time-consuming, expensive strategies. Also, one resource is not likely to get you there all by itself. What you must want is a team of experts who work together to help you achieve your EDA implementation. Yes, it takes a village.

When seeking a partner be sure to evaluate candidates thoroughly. How long have they been in business? How many EDA projects have they completed successfully? How many trained experts are on staff and available to you? What is their fee structure? How do they handle failure?

Most important long term, however, is to learn what their real policy around “knowledge transfer” is. Will they work hand-in-hand with your personnel, teaching them as they go so that you are self-sufficient when they leave? Or will they try to force you into an expensive, ongoing support engagement? To be certain, check out their methodology and their documentation. Read more.

Tiempo Experts Can Assist You with Each Step of Your EDA Journey

Tiempo’s expert consultants can help you develop a strategy designed around your organization’s target objectives. Client engagements start with a conversation, allowing us to learn about what you do, how you work, and what problems you’d like to address with regards to your application architecture. From there, we’ll assess existing systems and processes, define your requirements, and chart your path toward transformation. Contact us today to learn more about our software architecture consulting solutions.

 

Event-Driven Architecture eBook CTA