Evolving your automation (Pt.1): Why it’s worth upgrading to Red Hat Ansible Automation Platform 2.7

The release of Red Hat Ansible Automation Platform 2.7 marks the beginning of a new era for Red Hat automation. AI capabilities—including a Model Context Protocol (MCP) server, automation intelligent assistant, and the automation dashboard—are just some of the key features included in the latest release. 

However, a common theme with some of our customers is that they remain several versions behind the newest release of Ansible Automation Platform, effectively limiting their ability to scale automation within their organization. 

So, you may be wondering: With all of the new capabilities, why stick with an older version of Ansible Automation Platform instead of upgrading to a newer one?

Modern Ansible Automation Platform and its containerized architecture

One of the key differences between newer versions of Ansible Automation Platform and its predecessors is a reliance on containers as its runtime vehicle. Ansible Automation Platform 2.7 represents the completion of Red Hat’s multiyear journey to fully containerize the platform. As a result, the installation methods have been simplified.

The Red Hat Package Manager (RPM)-based installation option has been removed to instead focus on a container-first strategy for all aspects of the platform. But does that mean you need to abandon where you’re deploying Ansible Automation Platform today and upgrade to a Red Hat OpenShift deployment? No—both a virtual machine (VM) and an OpenShift-based deployment are supported.

Deploying Ansible Automation Platform within Red Hat OpenShift has been an option since 2018, and each release brings a new set of features, capabilities, and stability to the Ansible Automation Platform operator. For those currently running Ansible Automation Platform on Red Hat OpenShift, upgrading to the latest versions of Ansible Automation Platform is not only straightforward but streamlined.

Customers who are currently using an RPM-based deployment or running older versions of Ansible Automation Platform or Red Hat Enterprise Linux will need to make some decisions on their future runtime environment and how they forge their journey as part of the upgrade process. This may involve a migration and a platform shift.

Alignment with a container-first strategy

Large architectural shifts in Ansible Automation Platform are not new; they’re necessary to make sure the platform can modernize, scale, and meet enterprise demands.

Consider the transition in ansible-core 2.9, when Ansible Content Collections were split off and delivered independently of the core product. While that shift caused some initial tension, requiring automaters to make changes to their development process, the long-term success of the automation ecosystem demanded it. Today, modules develop independently from the core product, allowing for faster development cycles and helping partners create collections without waiting on or rushing code to meet a monolithic release date.

Likewise, the containerization of Ansible Automation Platform allows individual platform features to develop, update, and scale separately from one another. This decoupling helps introduce new capabilities to users who need them most without forcing a massive, synchronized update across every single component of your automation environment. By extending this reliance on containers all the way down to the infrastructure level, new features and bug fixes can be delivered with the agility the modern enterprise demands, while also providing the customization capabilities to make the platform solve your most important automation challenges.

Security and modularity: The organizational benefits

Ansible Automation Platform has always focused on strengthening automation within the bounds of enterprise governance. A containerized architecture doubles down on this philosophy in 2 major ways:

• True modularity: Deploy only the Ansible Automation Platform features and components you and your organization want—freeing up resources and streamlining use of the platform.
• Enhanced security: Ansible Automation Platform now runs natively in rootless containers, significantly hardening the security posture of your deployment compared to traditional RPM-based installations.

Navigating future architectural decisions

Moving from an older version to the modern architecture of Ansible Automation Platform 2.7 requires you to make key choices based on platform requirements, organizational goals, and user preferences. Helping you navigate some of these questions and their impact so you gain the confidence needed to execute a platform upgrade is exactly what we’ll cover in this blog series.

What's next?

Upgrading to Ansible Automation Platform 2.7 is more than a routine maintenance window—it’s an opportunity to optimize your automation infrastructure for the next decade. You can explore more in the Ansible Automation Platform 2.7 release notes and this webinar about new features. 

Stay tuned for part 2 of our blog series, where experts from Red Hat Consulting will share their expertise on specific architectural decisions you need to make to design and deploy the ideal containerized automation topology for your team. 

Red Hat Consulting is actively supporting customers across the globe in accelerating their upgrade to and adoption of Ansible Automation Platform 2.7. If you want to explore how we can support your automation strategy, contact your Red Hat account team or Red Hat Consulting directly.