The News: AnsibleFest, Red Hat’s annual gathering for all things Automation kicked off recently and unsurprisingly the team launched the latest version of the Ansible offering, Ansible Platform 2. Read the Red Hat announcement here.
Analyst Take: It has been almost 6 years since Red Hat announced its intention to acquire Ansible and the product has come a long way since those early days. The original acquisition rationale back in 2015 was to ride the wave of Infrastructure and Operating System automation market growth. According to an analyst only session before AnsibleFest kicked off, the Red Hat team now has much broader ambitions. While the existing Ansible products and the automation market as a whole has been focused on Infrastructure, Network and Security Automation and Deployment to date, the team laid out their plans to focus on Automation-aaS, Event Driven Automation, a push into edge uses cases and ultimately a longer-term shift to DevOps and Low Code environments.
The team laid out a four-pronged approach to delivering this roadmap. Initially the team is focused on expanding the routes to market and while details were lacking surely this will involve leveraging IBM’s large client footprint and sales force. Secondly the team talked about driving adoption, this included offering existing Red Hat clients and those looking to make the switch from Chef and Puppet 2 weeks’ worth of Red Hat Services, through an engagement model designed to maximise a client’s investment and ROI on any investment in Ansible. The team then outlined how the plan to expand the Total Addressable Market through the expansion into adjacent markets in the focus areas I outlined earlier. Finally, the team plans to strengthen differentiation. Details on the final point were less forthcoming, but I expect to see more on this topic in further announcements as Ansible goes into full production deployments with V2.1.
Enterprise-wide Automation through Ansible
The demands on IT organizations to support rapid innovation at-scale, only increases year-on-year. As part of this continued pressure to deliver more, faster, with a smaller team Automation has become increasingly a go-to strategy. Part of this strategy is effectively connecting existing IT and process siloes holistically across the organization. Against this backdrop a solution that can span the traditional IT operations use case through the network, to event driven automation to the Edge holds appeal for companies in many markets.
Businesses are increasingly looking to build alignment across product lines and IT teams to set appropriate standards for how automation can be invoked. Ansible Automation Platform 2 looks to make it easier to create automation, share it across the organization and then deploy it at scale to connect workflows with consistency and reduced cost.
With increased demand for speed and scalability the team at Red Hat have taken the opportunity to re-architect Ansible to deliver on the new challenges posed by the market. They have gone deeper than just adding new features but have taken a more fundamental approach with the version 2 Automation platform. One example is the new capabilities with automation mesh which bring greater consistency to support scale and complexity across diverse environments with dispersed edge networks, which will enable the Red Hat team to drive into adjacent markets and increase the applicable use cases for Ansible in the months ahead.
Container Native Architecture
At a technical level the Red Hat team has been busy. On the deep dive call, Richard Henshall, Senior Manager of Ansible Product Management walked us through the technical and architectural changes of which there are numerous. What stood out most to me at first blush was the feature terminology so let’s get that out of the way first:
- Ansible Engine is now automation execution environments
- Ansible Tower is now automation controller
- Automation Analytics components are now within Red Hat Insights
The rationale from the Red Hat team is that the company has re-architected Ansible Automation Platform to be container-native, and introduced a number of new features designed to expand the use cases and scale what is possible with automation. The focus for Ansible Automation Platform 2 can be most simply described as a focus on how customers; create, manage and scale their automation deployments.
The primary architectural difference over the existing Ansible 1.2 structure and what was launched with Ansible Automation 2 is a focus on Increasing automation content velocity by separating release of Ansible content from executables and creating new packaging called Ansible Content Collection to house curated modules, plugins, roles and components. While the long standing Ansible Tower has served customers well over the years the team stressed that as deployments scale and evolve beyond the traditional infrastructure use case there was a need to decompose the Tower stack. One use case highlighted by the product management team was Edge, where the sheer numbers of deployment endpoints necessitated a different approach. Therefore, Ansible Automation 2 has focused on increasing scalability and enabling highly-distributed edge architectures through containerization and separation of control and execution functions.
The other major improvement in Ansible Automation 2 is an improved developer experience with new tools for automation content creation. The Ansible Content Collection now includes 90+ certified content collections, comprising over 40,000 modules that have been curated for consistent, compliant delivery. This gives a huge library of existing automation options for teams looking to build their own approach, and means that very rarely will teams have to start from scratch to develop their use case, rather they will look to draw down from the huge catalog and then develop forward. This means not only increased deployment velocity but also a reduction in costs.
Breaking Down the Core Changes
Ansible Tower has long been a staple of the Red Hat Automation landscape and that has all changed with the new Ansible Automation 2 structure so let’s focus in on the core changes. Ansible Engine is now automation execution environments:
Ansible Engine is now called automation execution environments – Automation execution environments are container images on which all automation in Ansible Automation Platform is run. With a move towards a container native architecture, they provide a defined, consistent, and portable environment for executing automation, and allow for easier administration of Ansible Automation Platform by a platform administrator. With execution environments, Ansible Automation Platform has been able to move to a distributed architecture. Having the automation execution decoupled from the control plane is the breakthrough delivering faster development cycles, improved scalability which is crucial in Edge deployments, reliability, and portability across environments.
Ansible Tower is now called automation controller – Ansible Automation Platform includes the automation controller as a core component, this allows customers to define, operate, scale, and delegate automation across their enterprise. Automation controller is the control plane for automation, and includes a user interface, browsable API, role-based access control, job scheduling, integrated notifications, graphical inventory management, CI/CD integrations, and workflow visualizer functions.
Automation Analytics components are now within Red Hat Insights – Red Hat Insights continuously analyzes platforms and applications to predict risk, recommend actions, and track costs so enterprises can better manage hybrid cloud environments. Insights is included with almost every subscription to RHEL, OpenShift, and Ansible Automation Platform. I will need to get a full update on Insights in the coming weeks to understand the interactions with RHEL and OpenShift, but overall, I see this a good development for customers looking for insights (excuse the pun) across their Red Hat deployments.
Looking Ahead
I was encouraged that Red Hat have worked extensively with sponsor users in bringing this heavily re-architected Ansible Automation offering to market. The team outlined how 10 beta clients have actively been involved in the latter stages of the product development process. When I quizzed the team on the migration tasks that clients will have to undertake to move from 1.2 to 2 the team had solid answers that show they have thought through the challenges and have a robust approach.
I firmly believe that customers will be excited to see that automation execution environments now allow for greater portability of standardized sets of automation resources. This new approach will help drive self-contained automation, even shifting automation left into the development process which aligns with Red Hat’s ambitions to both expand adoption and move into adjacent TAM.
A key benefit of the new architecture of Ansible Automation Platform 2, will be that customers can expand their use cases and integrate automation as a single tool to manage a variety of areas. Teams can push to the edge and automate operational and IT scenarios from one toolset, ultimately making it easier to manage hybrid cloud environments.
The push towards containerization of the new platform can allow organizations to scale up and scale out their cloud deployments, while also managing their existing, on-premise datacenter and infrastructure activities. This re-architecture will enable Red Hat to address the increasingly important issues brought about by scale in customer environments.
However most crucially the new architecture opens up new possibilities for more complex automation that spans heterogeneous environments and uses cases. The platform’s new modular approach enables an event, wherever it may occur, to send data back to the control center to make a decision without human intervention. This opens up interesting use cases for event-based automation that expand beyond the traditional use cases for Ansible. This means customers will get additional benefits from their initial investment long after the initial sale.
Another key benefit of breaking up the previous Ansible Tower architecture into a container native architecture is that it allows for composability. In practice this means that heavyweight tasks can occur in the datacenter, while lightweight tasks can run at the edge. This will enable customers to build and execute automation in different ways, so they can focus on big picture innovations with a more efficient solution.
Overall, when vendors take a thought through and more foundational approach to addressing the needs of not only their existing customers but also the markets they hope to enter, and stretch themselves beyond just adding new feature/function I am bullish on their prospects. That is certainly the case here with Red Hat Ansible Automation 2.
Disclosure: Futurum Research is a research and advisory firm that engages or has engaged in research, analysis, and advisory services with many technology companies, including those mentioned in this article. The author does not hold any equity positions with any company mentioned in this article.
Other insights from Futurum Research:
Red Hat Partners with Nutanix to Put Squeeze on VMware
Red Hat Announces Latest Version of Red Hat Advanced Cluster Management for Kubernetes
Image Credit: Ansible
The original version of this article was first published on Futurum Research.
Steven Dickens is Vice President of Sales and Business Development and Senior Analyst at Futurum Research. Operating at the crossroads of technology and disruption, Steven engages with the world’s largest technology brands exploring new operating models and how they drive innovation and competitive edge for the enterprise. With experience in Open Source, Mission Critical Infrastructure, Cryptocurrencies, Blockchain, and FinTech innovation, Dickens makes the connections between the C-Suite executives, end users, and tech practitioners that are required for companies to drive maximum advantage from their technology deployments. Steven is an alumnus of industry titans such as HPE and IBM and has led multi-hundred million dollar sales teams that operate on the global stage. Steven was a founding board member, former Chairperson, and now Board Advisor for the Open Mainframe Project, a Linux Foundation Project promoting Open Source on the mainframe. Steven Dickens is a Birmingham, UK native, and his speaking engagements take him around the world each year as he shares his insights on the role technology and how it can transform our lives going forward.