BLOG: Red Hat AnsibleFest 2022 – Recap – The Culture of Automation

Ian Wright
Systems Engineer

Yesterday I returned from AnsibleFest 2022. Unfortunately, due to some long-standing plans, I had to miss the second day of sessions and the big party on Wednesday night, but I feel like I got to attend the most important parts and I wanted to do a quick write-up for those who didn’t catch my stream of posts to LinkedIn over the days that I was there.

Let’s just start with saying that the experience was pretty surreal. I’ve been at some big conferences in my time, but it’s been a while. Being in the room for the keynote addresses was amazing as there were so many people in attendance. It was definitely an exciting experience.

Beyond the sometimes-overwhelming nature of the conference, there was a lot to learn. The team running the show seemed to get caught off-guard by the popularity of some of the sessions leading to many people standing in long lines; and, I’m told, changes were made on Wednesday. But even with the crowd issue it was a great place to learn from people who are really using Ansible in their automation journeys.

But I’m a nerd. I really love learning about the newest developments, so the keynotes were really exciting for me. Let’s touch on a few points that came across in the keynotes.

 

Culture of Automation

 

Red Hat opened the first keynote with several points about Automation being about the culture of the business. In addition to the quote below from a “Fortune 15 technology company”, they also discussed how Discover had approached Ansible with what they called “Extreme Automation”. This was their plan for trying to automate any task that could be automated.

The core point with this is that Ansible is a technology that you can implement. But implementing it on its own doesn’t necessarily have a transformative impact on the business. If you really want Automation (and Ansible) to live up to its potential, that involves looking at all the ways you can transform your business culture to take advantage of it.

This means things outside of Ansible. It means treating scripts as parts of critical infrastructure and managing them with sound Source Code Management principles. It means getting script owners away from treating their scripts as a personal project that’s stored on a network drive or a laptop and taking advantage of Git to manage changes and implementation (i.e., Infrastructure as Code, or IaC), and to make certain that everyone who needs access to them has access to them.

It means using Automation as the standard, instead of ad hoc CLI/GUI work and scripting. If a server needs to be configured, the culture should assume that Ansible will be used to automate that process rather than having individuals login as root and exposing the server to all of the security concerns that go along with root access.

It means looking outside of IT itself and trying to find every place in the business that can benefit from Automation. That may be in places that you weren’t expecting before. Especially as automation begins to be facilitated by Edge Computing.

 

Public Cloud Providers Love Ansible

 

Everyone knows that Ansible is great in the data center. But what about the Public Cloud? Each cloud provider typically has its own way of automating deployments and managing configurations. So, why would users want to have Ansible?

Well, there’s a couple of reasons that I can think of:

1) Multi-Cloud is the way of things for many customers, particularly large customers. Do you want to put your IT completely into a single public cloud provider? They might give you a good price for that, but it also removes any leverage that you could have in negotiating your price. By using Ansible, you have the same tool running in each cloud provider. This means that when you’re setting up a playbook in Azure, it’s using the same processes that you would use in your Data Center and in AWS.

2) Do you want to have your users going to the console for your public cloud provider? There will certainly be some who need that access, but generally speaking if they want to deploy a server, is that the most secure way of running things? Or is it better to have Automation set in place to handle the deployment? With Ansible you can set up the processes that users need access to in the Automation Services Catalog and have them run in the appropriate cloud behind the scenes, without any need to connect to the management layer of your public cloud.

With this in mind, Microsoft Azure has been in Beta with their “Ansible Automation Platform on Microsoft Azure” for some time now. It’s a managed service available through their marketplace. By purchasing it, billing is handled through Azure and it deploys automatically on top of their Azure Kubernetes Service (AKS). It’s fully managed and scales as needed. You get all the Automation (even Automation in other clouds or your data center), without maintaining the infrastructure where it runs.

In addition to Microsoft Azure announcing the General Availability of their offering, AWS was on hand to make their own announcement. AWS is now offering a Red Hat Ansible Automation Platform managed service in the AWS marketplace. As with the Microsoft Azure offering, the AWS offering will be billed through the AWS marketplace and will come from resource commitments in your contract.

The big value of both offerings is that you can just start doing Automation from day one and not worry about any of the tasks that you might have to manage otherwise. This also means that Ansible is available across everywhere that you could want to automate from your local data center/private cloud to the major public cloud providers.

 

Ansible Validated Content

 

Ansible has been great at making sure that customers get the support that they need on whatever they want to automate. I’ve really been impressed with the Ansible Certified Collections. For those who may be new to Ansible Automation Platform, a collection is a grouping of related content (modules, plugins, and roles) that can be downloaded for a particular purpose or product. For example, if you wanted to automate IBM FlashSystems, you could download the collection ibm.spectrum_virtualize from Ansible Galaxy or Github. This collection will do a wide variety of tasks for IBM FlashSystems for any user of Ansible including the “upstream” users of the Ansible project.

But when you’re paying for Ansible Automation Platform, one of the things that you are paying for is support. Now, supporting Ansible itself is one thing but what about content that wasn’t created by Red Hat but is freely available on the internet? That gets a bit trickier.

So, a few years ago Ansible Certified Collections were introduced. These are collections for Ansible for which Red Hat has agreed to provide support. This means that if you’re using the IBM Spectrum Virtualize collection downloaded from the Red Hat Ansible Automation Hub and you encounter a problem with the collection, Red Hat is able to support it… and there are many vendors that participate in the Certified Collection program.

This week Red Hat built on that by introducing Ansible Validated Content. This goes beyond providing modules, plugins, and roles that can be used to do Automation. This is an “opinionated path for performing operations” on both Red Hat and Third Party platforms and which have been developed by Red Hat and partners. Importantly, these paths (which will be available in the Private Automation Hub), have been tested for security, along with quality and reliability. But they are also meant to give users “turn key” solutions (including roles and playbooks) to get up and running quickly as they start to deploy Ansible in their environment.

Summary

So, that covers my updates from the first day of AnsibleFest. The Day Two keynotes had even more interesting information that I will cover in a follow-on Red Hat blog.

For further assistance with Ansible Automation Platform, or to discuss best approaches for deploying IT Automation in your organization or enterprise, please reach out to me or to your Account Executive or contact us here.

You may be interested in:

Video: Red Hat Ansible Automation Platform 2.x (10:13)

BLOG: All Things Red Hat: Enterprise Open Source Solutions