Ops as Code and the event-driven era

The following is an excerpt from my AnsibleFest keynote at Red Hat Summit today.

Automation is nothing if it’s not solving a problem.

One of the best parts of our jobs is getting to see what our customers are doing, because the ingenuity they apply when using our product to solve their technology and business challenges never ceases to inspire. Our customers have pushed boundaries, and pushed us to continue to improve Red Hat Ansible Automation Platform, and deliver new capabilities. And sure enough, our customers have used Ansible Automation Platform to achieve remarkable gains in how quickly they are able to provision and configure their infrastructure, deploy applications, manage networks, security, cloud and more.

But we automators find ourselves at an inflection point. We’ve built a strong foundation. But how can automation help us solve the next set of problems, to get to the next level of operational efficiency?

• How do we enable app teams to access our increasingly complex and sprawling infrastructure?
• How do we ensure consistent, reliable configuration?
• How do we make sure that the right policy securities are applied?
• And how do we do all this as widely as possible, for as many people as possible?

Then, importantly, execute securely and be able to prove what we did or are going to do.

Employing an Ops as Code approach
So what do I mean by “Ops as Code?” It’s a simple enough idea in theory. Ops as Code is built on the same promise as Infrastructure as Code or Config as Code; to allow known sequences of tasks to be executed in a repeatable, scalable way - and by doing so, reduce toil and help teams move faster.

But we view Ops as Code as an elevated progression from those other two terms. We’re talking about taking the accumulated knowledge of Ops, infra and app teams - all the context they’ve learned by working through problems - and codifying it in Ansible Playbooks and in our new Event-Driven Ansible solution, which uses Ansible Rulebooks. These rulebooks are also supplying your team with great documentation. The same approach we’ve been promoting with Ansible from the start.

Doing so means that operational knowledge doesn’t just live with individuals on teams. The “how to” of Day 2 is converted into code - into something tangible that can be executed as systems become increasingly intelligent and complex, and importantly connected. And that’s always been the goal, right? As more and more tasks get automated, a larger variety of problems can be identified and addressed more quickly - freeing up people to focus on tackling new challenges.

Ops as Code isn’t about replacing people or processes, it’s about how we extend and move further to completing the automation story we’ve been advancing over the past decade. So that the same benefits and lessons from automating one stage of our systems lifecycle can be applied to more of that end-to-end. We are building on our foundation and applying those learnings to other areas where there is a problem that needs fixing.

This is where we really need to level up our thinking and expand our conception of automation across the entire lifecycle. We have our existing systems, our cloud systems and many of us will have edge systems. This goes back to the power of “and” ⎯ whatever your teams are planning and doing, they should be thinking “... and automation, too.” Infusing your automation strategy into the very DNA of all your operations is the path to achieving truly transformative end-to-end automation.

So, Ops as Code is the approach that we think offers the best chance to deal with your tech sprawl, with pressured resources, in the places you need to be, taming the complexity.

But there are two other factors to consider as well:

1. How does automation content get created and shared? This is where Ansible Lightspeed with IBM Watson Code Assistant comes in. An Ops as Code approach can help organizations really get more from AI. As SMEs use generative AI as a tool to help them create automation content, they are training data models with invaluable contextual expertise. This context is then codified, goes back into the model and makes everything stronger. A virtuous cycle that is our end goal for bespoke, customer trained data models. This is why “as Code” is so important.
2. How does all the automation you’re creating get triggered? With Event-Driven Ansible. You were already introduced to Event-Driven Ansible, but let me tell you why it’s going to change how you think about automation.

Why the next wave of automation is event-driven
Event-Driven Ansible represents an exciting next step for organizations and teams to take their automation to the next level, which has been the driving force of our product roadmap for a while.

You’ve got a variety of solutions and tools collecting data and identifying problems. When they find a problem, they raise a ticket and send an alert. What happens when you get that alert? You call it out to someone whom you hope is the right person. In the meantime, time is money. If the issue is mission critical, you have pressure building and dependencies at risk while you wait to get things sorted out.

All of these steps, and the real irony is this: How many problems do we have that are fixed by a known solutions pattern? We may know the answer, but someone has to log on and fix it. This takes a lot of time while there is an issue or outage.  

Event-Driven Ansible offers a better way. It builds on what makes Ansible so popular ⎯ broad applicability and ease of use ⎯ and expands to tackle the problems we’ve discussed here today. Event-Driven Ansible introduces some new concepts, but in a very familiar architecture with sources, rules and actions.

For individual Ansible users, they can use their existing skills and experience from day one. They’ll be able to use Event-Driven Ansible to translate thought processes for common problems ⎯ and their solutions ⎯ into Ansible Rulebooks, which function in a similar way to Ansible Playbooks.

And at an organizational level, Event-Driven Ansible, as part of Ansible Automation Platform, helps scale these solutions to extend efficiency across all of your existing investments. We integrate Ansible into sources of information - things that normally trigger a manual response, then we can run the automation you’ve already built.

Because ultimately, you can write all the automation you want for operational activity, but you have to be able to run it when and where you need to run it. And that’s what Event-Driven Ansible is designed to help you do: Receive, decide and respond.

This model is great for issue remediation, but it has many additional applications – like controlling configuration drift, responding to changing conditions, ticket approvals, and response to security incidents. There are many places in your lifecycle you can respond to a known event without manual activity.

If you’re ready to learn more about Event-Driven Ansible, we have a ton of great content for you to explore.