Event-driven automation: What’s in an event-driven automation architecture?

Automation of daily tasks is impressive by itself, and is incredibly helpful when working toward improving operational efficiency. However, as discussed in Part 1 of this series, this only scratches the surface of an event-driven solution, which takes standard automation and elevates it by providing benefits like accelerated IT emergency response and tactical compliance, advanced systems security management to recognize event occurrences, and even creating a formulated response that is ready to react. This solution can be further enacted across your entire organization to continue to build beyond Day 2 operations. 

In this article, we’re going to outline the architectural components required to help lay a conceptual framework to later build upon. One thing to note is that most of the components being discussed here are customizable to fit your exact business needs or preferred technology. We’ll provide references where Red Hat has specific technologies along the way, but we want to simply outline the components of the solution so you have an open choice for the technology that best fits your needs. 

Let’s review the logical diagram of this architecture, below (Fig. 1). Within the External Platform box on the right, you’ll see we have the event sources, ticketing system and managed infrastructure. There’s also the hosting platform for the Data Center or Public/Private Cloud box on the left, where we have a messaging layer, automation orchestrator, microservices layer and some intelligent routing. 

Fig. 1 - Event-driven logical diagram

Together these support event-driven automation, which we will break down into three segments. First, the event discovering what happened. Second, the drive formulating a response to the event and documenting/logging tasks along the way. And third, the automated response using automation to deliver the solution.

• Event is an event source notifying of the event and a messaging layer to receive the event and handle communications to and throughout the solution.
• Drive is where intelligent routing decisions are made and where microservices will handle the executable actions between the messaging layer, storage locations, ticketing systems, etc.
• Automated response is how the automation orchestration in this solution will execute on the determined response.

Event

Event source

Beginning with an event source, you can choose from your favorite monitoring tool(s), like Prometheus, Zabbix, Nagios, Sensu, etc. Whether in an event-driven architecture or not, this monitoring component is key to making sure you’re maintaining a safer and more secure environment that can capture data concerning discovered vulnerabilities, compliance risks, system drift and the many other things that often plague a system administrator’s maintenance workload. 

Messaging layer

Fig. 2 - Messaging logic 

We next require a messaging service to translate an alert from the event source into the appropriate protocol for sending through this workflow (Fig. 2). In addition, messaging between the services mentioned below delivers consistent and efficient communication between each microservice. In our case, we delivered this solution using Red Hat AMQ Streams as the foundation for efficiently sharing data between microservices. 

Many users are likely already familiar with everything up to this point. Given the importance of monitoring, the messaging of alerts is typically set up in tandem to email a system administrator of any found issues or anomalies with this, but it still requires manual intervention from those admins. So, when considering whether elevating automation into event-driven is a daunting task or not, it may help to view this as simply tying two solutions that you may already have together, to deliver an even more powerful joint solution. 

Container platform

The container platform is the foundation on which our automated solution is built. The messaging and microservices layers as well as automation orchestration (discussed later) are all containerized applications built for flexibility, portability and efficiency. For this solution, Red Hat OpenShift helps build and scale business-critical applications more consistently across a hybrid cloud environment.

Drive

Microservices layer

Fig. 3 - Microservices logic

Transitioning into the drive mechanisms of this solution, we have a few main services powering the formulation of the response. The system event service (Fig. 3) handles the main sorting of events, based on priorities established by the intelligent router (covered in the next section), and messages back out to the services layer what sequence of events will be followed. The Manage task service handles the management of logging and ticketing each task of the event response. And the automation services invoke the automation orchestrated response and the processing of results for sending back through the solution for updated logging. Red Hat Fuse is our distributed, cloud-native integration platform that allows services to be decoupled, allowing for independent creation, extension, manipulation and deployment.

Intelligent routing

As a monitoring service or even multiple services scan an environment and begin to report events, there are rarely just individual events that come in single-file, needing equal priority. An intelligent router helps define a set of rules to prioritize simultaneous events, giving the system event service an operational workflow to distribute to the rest of the solution. 

To give an example, you may have a specific application that’s trailing a version or two behind, and some new features were recently added that aren’t yet available to you. A notification is sent from the event source to perform an update of that application. However, at the same time, a network monitor just discovered a high amount of traffic that looks to be targeting a specific server, and alerts of a potential DDoS attack. While it’s still important that this solution processes the update of the new application release, the targeted attack is clearly a much higher priority. Logic can be written to handle the highest priority tasks without delay, resulting in an emergency response that can be delivered as close to real-time as possible.

Automated response

Automation orchestration

Fig. 4 - Automation logic

Finally, the event has been prioritized, logged, and automation has been invoked, pushing a solution out to the managed infrastructure. Automation orchestration now handles the processing of multiple similar events, aligning the appropriate solution with each applicable event, and executing the response on each applicable system. With Red Hat Ansible Automation Platform, this orchestration is simplified, as Ansible is able to handle multiple events simultaneously. Pairing similar events together, sending playbooks out to execute in batches and monitoring the returned results, Ansible is able to remediate the issues, and efficiently report back through the chain of messaging and microservices listed above for completing the tracking of each event. 

Tying everything together, this solution makes a highly complex orchestration of tasks a bit more manageable, and ultimately self-sustainable as it functions within your organization. As mentioned in my earlier article, if you’d like to take a closer look at how our customers are using event-driven technologies in their industry, check out this architecture in full.