Lighthouse Blog

  • Lighthouse Blog
  • Navigating the Decision Process: Community Ansible vs. Red Hat Ansible Automation

Navigating the Decision Process: Community Ansible vs. Red Hat Ansible Automation

Navigating the Decision Process: Community Ansible vs. Red Hat Ansible Automation

Lately, automation is playing a larger role in companies’ digital transformation strategies. For example, it’s coming up in conversations about moving to the cloud, enabling network patching, and supporting day-to-day tasks across different lines of business. If you are wondering where automation should come into play at your business, there are two important things to consider first: 1) Which automation platform will you use, and 2) Why will you use it?

Ansible, for instance, is a popular choice for businesses’ automation needs. There are two paths to take within Ansible. One option is to use the open-source, community version of Ansible. The other is purchasing Red Hat Ansible Automation Platform. Though similar in nature, there are some big differences between the two choices when it comes to scalability, security, and building content.

Making the right choice for your company means understanding the differences between the two options. Here, it’s important to read the fine print. Or you can get help from an expert who has. Let’s look at some key differences between the two options to help navigate the decision.


Key differences between Community Ansible vs. Red Hat Ansible

The community versions of Ansible, AWX and Ansible Engine, are effective tools for testing the “automation waters” in a non-production environment. AWX is an open-source project. Because of this, it is less secure than Red Hat Ansible Automation. Here are some other important differences:


Validated content vs. from scratch

When assessing the ROI of Red Hat’s Ansible Automation, one measurement often considered is time spent. An analogy I like to use to understand the difference between the community version of Ansible and a supported Red Hat subscription is the process of making dinner in your own kitchen on a weeknight.

After a long day of work and juggling all of our other responsibilities, we thankfully have choices when it comes to preparing dinner. On my commute home I think of what I’d like to eat for dinner (often a painful process for me), then stop at the grocery store to gather the raw ingredients, unpack those groceries at home, spend the time preparing ingredients by chopping, measuring, etc, follow the recipe I found via searching online and then hoping my meal looks and tastes as good the online recipe.

Another option I have is a meal kit delivery service, which is a type of subscription service that sends me pre-proportioned ingredients and a recipe card. This enables me to cook freshly prepared meals at home without the effort of having to research, shop and prepare ingredients. Most of the hard work has been done for me – where all I have to do is open up the packets, pour a glass of wine and get cooking, saving me valuable time.

In this analogy, the self-prepared home cooked meal is like the upstream version of Ansible. While I still get the access to Ansible Galaxy for modules, playbooks and roles it does require a bit of sweat equity and time – research, validating content and developing. With Red Hat Ansible Automation Platform I have access to Automation Hub, providing access to pre-built, vendor-specific, certified modules and playbooks.


IT scalability requirements

Another important difference involves user experience and visibility. When it comes to Red Hat Ansible Automation, it is a truly scalable solution that will fit in any size IT department. It allows for IT departments to reduce cycles on monotonous tasks and focus on higher value, revenue-driven initiatives. 

Ansible works across multiple lines of business (LOB), including but not limited to: Networking, Security, Windows/Linux, HR, etc. Tower adds flexibility and enhances orchestration across these LOBs. In a datacenter without Ansible, these LOBs are siloed out and have a tougher time communicating. Having an Ansible footprint will help alleviate communication issues between the LOBs.


Security considerations

Many users must consider support, stability, and security when it comes to implementing different software solutions. When it comes to meeting overall compliance and standard regulations, all Red Hat platforms are secured, supported, and stabilized for all customers. Support levels come in 8x5 and 24x7 SLA options, and customers can expect the latest versions, patches, and updates for the lifespan of the product.

AWX code has not gone through the same QE process and does not include security-harden images—while Red Hat runs a security test for every release. Also, with AWX being an open-source project, there is a higher chance that a third party could access internal information and infrastructure without Red Hat hardened security. It is important to consider these factors early in the process, especially when running Ansible in a production environment.



Balancing the bottom line with the needs of IT

When it comes to vetting these two similar, yet vastly different solutions, it is important to remember that both play an important role in the IT footprint. Many IT decisions are made with the bottom dollar front-of-mind. However, the Ansible decision needs to accompany questions such as “Is this for the development or production environment?”, “How will I handle patches and upgrades?”, and “Do I have time to build content from scratch or should I utilize validated content in the Automation Hub?”

These few questions only scratch the surface when deliberating, so reach out to today to ask how we can help to navigate the decision process between Community Ansible or Red Hat Ansible Automation.


Related Posts
Analytics Supporting a High-Value Automation Strategy with the Red Hat Management Portfolio
Hybrid Cloud Accelerate Your Cloud Journey by Reimagining Integration