What’s changing, why it matters, how it impacts your business, and where Red Hat Ansible Automation Platform fits in.
Ian Wright
Systems Engineer
A colleague once told me that, over time given the right conditions, eventually any hardware will fail. Conversely, over time and given the right conditions, eventually software will work. Amusing? Yes. True? I suppose it could be argued either way.
In the case of Ansible Automation Platform (AAP) and having just left a customer’s presentation at SHARE25 highlighting their use case on their mainframe, I can say that AAP works very well. However, over time, developers often discover that some initial implementations may no longer be the most effective or efficient approach for today’s evolving needs.
At Red Hat Summit 2024 Community Day, Matt Jones, Red Hat Distinguished Engineer and Ansible Chief Architect, discussed the issues with the way Ansible was developed and how the Ansible developers would like to improve the architecture.
While Ansible itself is a monolithic Django application, it is built upon numerous services that come from other open-source projects. This photo taken from that presentation (Figure 1 below) suggests how much is built into Ansible.
While containerized versions of Ansible exist, they remain fundamentally monolithic applications that have simply been “lifted and shifted” into containers. Whether it’s containerized AAP on RHEL or the Ansible Operator on Red Hat OpenShift Container Platform, the core structure of Ansible hasn’t changed—it’s still a tightly integrated codebase running within a containerized environment. All services are bundled together, making it difficult to modify one component without affecting others. This approach falls short of modern cloud-native application development standards, where modularity and flexibility are key.
Since the July 2024 release of AWX version 24.6.1, the AWX team has been working to refactor Ansible into a pluggable service-oriented architecture. This shift will enable the Ansible AWX team to focus on core functionalities, ensuring Ansible remains streamlined and purpose-driven-unlike many existing services in the current product that have expanded beyond its original scope. This has already resulted in substantial changes in the AWX project such as breaking out the UI, Inventory, and credential types. Additionally, the Helm Chart for AWX has been removed from Operator.io and releases are now handled via GitHub.
Users who previously relied on services that were part of the Ansible application will be able to integrate them into the new architecture to meet their specific requirements.
Figure 2 is taken from a blog post in the Ansible forums where the intent is described.
How does this impact my business?
Ansible vs AWX: Key differences
To understand the impacts these changes to Ansible can have on your business, let’s first take a quick look at the differences between AWX and AAP:
• AWX is the upstream open-source project; AAP is the long-term commercially supported version
• AWX is free; AAP is a paid subscription
• AWX is not intended to be run in production environments; AAP provides technical support, certified and supported content, hosted management services, and risk mitigation.
• AWX is a fast-moving open-source project where all new development is born; AAP is enterprise-grade and production ready.
Impacts on AAP Environments
Since development takes place in the AWX open-source project which is then systematically rolled out to the AAP offering, this change won’t impact you. At some point in the future, AAP will be updated based on what happens in AWX. So, you will continue to benefit from the development efforts in AWX.
Impacts on AWX Environments
Changes to AWX will, or possibly already have, impacted your production environment. Everything from the change from semantic versioning (24.6.1 was the final semantic version) to CalVer, along with the steady progress of the architectural changes will impact the stability of the platform. However, these shifts are a natural part of AWX’s evolution as an upstream development project shaping the future of automation.
This Ansible Forum blog details the future directional intent of AWX. The key statement is in the 2017 FAQ question about differences between Ansible Tower and AWX. It is stated “AWX is designed to be a frequently released, fast-moving project where all new development happens.” This describes precisely where AWX is headed in this change.
What you can expect is that the developers are going to be working hard to decompose the Ansible application and remove the services that are not part of the core of Ansible’s role. Pulling out these services can end up being like a game of Jenga… Pull things out in the right way and everything keeps going along well. Remove a service the wrong way, and you may have one or more parts of the application break unexpectedly.
Should I move to Ansible Automation Platform (AAP)?
If you have AWX in a sandbox or a lab environment where you’re comfortable with seeing how things are changing and understanding that it will break at times, and that’s all part of the process, then you don’t really need to do anything. And Red Hat and Ansible development really do need feedback on your experiences to help the development process.
But, if you’re using AWX in production, then you need to consider moving to AAP. Red Hat just never really intended AWX to be the “enterprise” class of automation, and it needs to be able to make these changes for the longevity of Ansible. It’s likely that you’re already experiencing disruptions with the changes, and it’s unlikely that we’ll see the former release process reinstated.
It’s also important to remember that AAP has integrated capabilities that aren’t part of the Ansible AWX project. For example, Event Driven Ansible (EDA) is a component of Ansible Automation Platform and has been rapidly growing in adoption since its announcement just a few years ago. Integrating EDA into AWX requires working with a separate upstream project and bringing it into your environment; likewise, with Ansible’s Private Automation Hub. You can also expect this to be the case with last year’s announcement of Policy as Code which will be available as an open-source project but will not be part of the download and installation of AWX: It will be with AAP.
How can I migrate to Ansible Automation Platform?
Mainline’s Hybrid Cloud solutions team can work with you to perform the migration of the PostgreSQL database to get you up and running on the Ansible Automation Platform whether that’s in a VM, OpenShift Operator, or the containerized version on RHEL.
Contact Mainline to start a conversation about your migration to AAP or your enterprise IT automation strategies or initiatives.
More Information
As an IBM Platinum Business Partner and a Red Hat Premier Business Partner, Mainline has extensive experience helping customers with IBM Enterprise Servers, as well as across the three pillars of Red Hat’s business: hybrid cloud infrastructure; cloud-native application development; and IT automation and management. To set up an in-depth discussion about how to get started using these open-source technologies, please contact your Mainline Account Executive directly or contact us here.
You may be interested in:
BLOG: Red Hat Ansible LightSpeed: AI Capabilities that Propel IT Automation