Digital business is here to stay, whether this means improving internal workflows or directly delivering capabilities that enhance the customer experience through applications hosted across the hybrid cloud. Once these solutions are built and deployed, smooth operation becomes the goal. 

Keeping the lights on with automation 

IT operations teams face challenges in Day 2 operations, such as:

  • ongoing security risk mitigation
  • scalability
  • upgrades and patches
  • surrounding technology and environment changes and impacts
  • consistency of change
  • keeping solutions updated
  • compliance needs
  • limited staff
  • skills gaps
  • hiring challenges
  • “agile” delivery of services
  • short mean-time-to-resolution (MTTR)
  • and more

Against this backdrop, IT automation solutions have been helping teams respond faster and with more consistency and efficiency.

For example, a team needs to patch 100 servers due to a newly-identified security risk. Red Hat Ansible Automation Platform can perform a task in minutes that would normally take hours or even days to complete. You can read about these very fast response times in case studies from Emory University and Blue Cross and Blue Shield of North Carolina. This type of automation is in use across IT operations of all sizes, because of the benefits in streamlining operations.

Observe and respond: Event-driven automation

So, what’s next? Event-driven automation is a way that IT teams can advance their use of automation even further. In the use cases above, Ansible Playbooks are created and then an IT staff member manually initiates their execution. This is a great model for large-scale changes, such as the planned patching of 100 servers.

In an event-driven model, the automation is contained in Ansible rules in the format of an if-this-then-that approach. Event-driven automation is ready and waiting to be triggered by an event, so it is good for responding to an observed event. For example, if a router is not responding, event-driven automation will create a ticket and reboot the router. Ansible rules (via Ansible Rulebooks, see below) remain always on–ready and waiting for events or conditions that trigger their use–enabling an automated response. 

Red Hat’s event-driven automation solution is Event-Driven Ansible, which works based on three constructs contained in a structure called an Ansible Rulebook:

Sources: Generators of events—for instance, a third-party monitoring tool that identifies and communicates when a web server is down. Event-Driven Ansible consumes events from third-party tools or your own custom sources using source plug-ins. Our ISV (independent software vendor) partners are currently working on creating plug-ins between their technology and Event-Driven Ansible, and you can create your own custom event source plug-ins as well.

Rules: Rules are conditional statements that attempt to match event conditions. Once a condition has been matched, a defined action can take place. For example, a rule may specify that when a web server is down, a service ticket is created and the web server is rebooted. While rulebooks and playbooks are both written in YAML, a rulebook specifies the event source, and is structured in an if-this-then-that approach. Note that existing Ansible Playbooks can be called within rulebooks as actions to be taken when conditions are met. Alternatively, actions can be directly described via modules. These rulebooks are ready when the event is communicated to the decisioning capability within Event-Driven Ansible.

Actions: Once a condition in a rulebook is matched, a corresponding action can be triggered. Some actions that can be triggered are the running of an Ansible Playbook, an individual module, a template in automation controller as well as the setting of facts or creating another event.

Figure 1: How Event-Driven Ansible works using sources, rules and actions. 

Figure 1: How Event-Driven Ansible works using sources, rules and actions. 

Why use event-driven automation? 

Put simply, it helps reduce the burden on limited staff, and is fast, automatic and consistent in the way it responds. The use cases can range from simple notifications and fact gathering to remediation or other technical actions. Event-Driven Ansible is flexible enough for teams to decide what level of response they would like.

Due to its versatile rulebooks and overall flexible architecture, Event-Driven Ansible is use case-friendly and can be used in departments across the organization to reduce routine and high-volume reactive tasks. Its YAML capabilities make it an ideal advanced technology for today’s Ansible users, and can maximize your investment in Ansible Automation Platform. It avoids long and sometimes costly IT services and projects to build event-driven solutions–so anyone across your IT team has access to the technology to help reduce the manual burden in ways that serve their needs. 

Figure 2: Automate across IT operations with Event-Driven Ansible which is flexible from source to rule to action, making it ideal for automating a variety of use cases. 

Figure 2: Automate across IT operations with Event-Driven Ansible which is flexible from source to rule to action, making it ideal for automating a variety of use cases. 

For IT leaders, this means operations can be much more responsive and resilient. For IT staff, this provides a better work-life balance and also reduces the need for manual responsive tasks, so teams can focus on the innovations that matter and take on more challenging work. 

Check out the IDC QuickTake from AnsibleFest 2022, which discusses Event-Driven Ansible or get started yourself


About the author

Cindy Russell is a Senior Principal Product Marketing Manager for Ansible Automation Platform.

Read full bio