Red Hat aims to unleash a new wave of automation with Event-Driven Ansible. Infrastructure as Code (IaC) provides the foundation, while Operations as Code provides the completion. This is with an eye toward end-to-end automation.
Earlier this year, Red Hat announced Event-Driven Ansible, and previews and features are now available. The idea behind the update is to change the way the automation platform handles playbooks. From now on, Red Hat Ansible Automation Platform can automatically start a playbook based on observed events. Previously, another software solution had to be used to observe and start the appropriate playbook.
A few months after the announcement, we were curious to learn more about the concept, vision and direction. We spoke about it with Craig Brandt, Principal Technical Manager Ansible at Red Hat.
The role of Event-Driven Ansible
Event-Driven Ansible aims to integrate automation into daily business operations. It does this by using observability – the platform listens for events. It then evaluates them, applying additional conditional rules. Event-Driven Ansible offers features for the creation phase, the operational phase and the scaling phase of automation and playbooks. For management, it has a Web UI, auditing capabilities, log-tracking and role-based access control, to meet the needs of large enterprise organizations.
Also read our story where we analyzed the unveiling of Event-Driven and further explained its foundations.
Addressing challenges
Brandt explains that Red Hat’s direction with Event-Driven Ansible is based on challenges that enterprises are currently facing. Automation professionals see the need to achieve more with automation, often with the same resources or even less. The pressure is on IT professionals to maximize the efficiency of automation, while at the same time implementing ideas from management. The ideas do not always lead to production.
Budget constraints also play a role in the area of automation. When creating and assessing an automation strategy, companies often notice overlap between different tools and functionalities, which does not favor automation experts in the battle for budget. They are sometimes asked to justify the value of the tools and get the most out of the various tools.
Another challenge is attracting and retaining automation experts. How does an organization find the right people and keep them engaged? Brandt also sees a growing demand to make automation-related expertise and skills more accessible to other experts within the organization, such as security, networking and infrastructure professionals.
The three phases of automation
According to Brandt, these challenges and needs lead to three phases of automation. He calls them “crawl,” “walk” and “run”. In that order, because it indicates how a company can move toward Operations as Code. The image below gives a rough idea of these phases.
In the first phase, crawl, IaC as we know it is applied. An automation expert focuses entirely on automating a specific infrastructure task. For example, in an enterprise environment, it means IT people automating 20,000 Windows servers. So IT people apply IaC purely for themselves, not necessarily for the rest of the organization.
In the next phase, walk, automation expands further. Here the perception of automation changes. Consideration is given to how automation can be treated more like a software asset. How can success from one part of the IT organization be translated to other teams? How can these teams become experts in automation so that more value is extracted from automation in the teams? This refers to the aforementioned desire for security experts and networking professionals, for example, to do more with the Red Hat Ansible Automation Platform.
However, Brandt sees a need to go much further with automation. This is where the “run” phase, Operations as Code and Event-Driven Ansible come in. In this phase, automation becomes much more integrated into the organization. The organization’s strategy is driven and supported by an automation platform. Automation activities are aligned with the organization’s strategic goals and are ideally measurable. This makes investments and new goals more easily accountable to management.
This touches the essence of Operations as Code. IaC remains the foundation, but automation shifts from focusing on making individual tasks more efficient to creating complete workflows. With this, Red Hat Ansible Automation Platform grows into a platform that connects automation to large-scale business processes and links business results to them.
A new wave of automation
According to Brandt, it makes sense for companies to determine what stage they are in. Based on that, they can make a plan, if they are not yet in the most advanced phase, to work toward the run phase. During a presentation before our conversation, Brandt also shared the questions below that can help determine the phase of an organization’s automation journey.
Brandt also argues that the shift to Operations as Code brings automation to where most of the work resides. Companies that have used Red Hat Ansible Automation Platform in recent years have developed all kinds of great automation with the platform. They have written playbooks for configuration and provisioning that have evolved the infrastructure to a certain level. In this new era of automation, the work is shifting more toward standardizing operational processes.
Route to end-to-end automation
Event-Driven Ansible marks a new era for automation. It is the path to end-to-end automation, with IaC as the foundation and Operations as Code as the next step. Organizations can thus integrate automation into their daily operations. That way, everything runs more efficiently and productivity increases.
Especially at a time when automation has become a differentiator for organizations, a path to wider adoption of automation is welcome. In this regard, Red Hat sees a golden future for the Red Hat Ansible Automation Platform, now that the platform includes Even-Driven functionalities.
22 hours ago
