If you talk about software automation with developers and devops, there's a good chance that Chef and Puppet will come up in conversation. In the last 18 months or so another name has joined them: Ansible.
Named after a fictional communications device, Ansible is an open-source automation engine that automates software provisioning, configuration management and application deployment. The project was founded in 2013 and bought by Red Hat in 2015 for a sum believed to be in excess of $100 million.
Ansible is very similar to Chef and Puppet, yet its Ansible that everyone seems to be talking about. And a quick look at StackShare's list of Top 5 Most In-Demand Devops Tools shows Ansible in third place in terms of job openings listing the tool as a required skill, just behind GitHub and Docker. Red Hat itself is also keen to back up claims of Ansible's popularity: Jim Whitehurst, the company's CEO, said recently that Ansible is included in about a third of all Red Hat deals.
So what exactly makes Ansible so attractive?
One reason it has gained momentum since being acquired by Red Hat may have been the acquisition itself, according to Paul Delory, a research director at Gartner. "We definitely have seen a bump in interest since the acquisition by Red Hat, because it now has more credibility in the enterprise," he says.
Part of the reason for this is that there was a perception in the software development and devops community that Ansible's support offering was not as good as that of Puppet or Chef. But under Red Hat's ownership this support gap has been closed, he says. "Support is important to enterprises, and the quality of support available is of critical importance," he adds.
But there's more to Ansible's popularity than the availability of decent support options, vital though those options are to enterprise customers. For devops in smaller companies, part of Ansible's popularity may be explained by the fact that it is easy to get up and running with the tool, according to Martin Rusev, a Berlin-based devops who works for a large organization as well as a number of smaller startups.
"That's a big benefit for small companies: you can get Ansible running without the need for a dedicated sys admin because it can be operated on by anyone," says Rusev. "With Chef and Puppet it takes much longer to get going because you need an understanding of each part of them."
But he adds that Ansible is also used in the large company he works at, and that many large companies use a combination of Chef or Puppet and Ansible.
One of the reasons for that, believes Gartner's Delory, comes down to the fact that Ansible is fundamentally different from Chef and Puppet in its design. Specifically, Ansible is agentless: it communicates with the servers it controls by sending them Ansible "modules." These programs are written to be resource models of the desired state of the system, and once Ansible has executed these models (over SSH by default) it removes them. By contrast, both Puppet and Chef use agents running on the servers the two tools control.
"There are pros and cons to both approaches, but because Ansible is agentless it has an easier time managing things like switches and storage arrays," says Delory. "Once you leave the realm of the server, the agentless approach is easier, and that's why you might find that networking (and storage) teams gravitate to Ansible, and server teams like Puppet and Chef." Similarly, developers like Puppet and Chef, which is built in Ruby, while devops prefer Ansible, which is Python-based. "Devops are typically familiar with Python, so that's definitely one reason why they may favor Ansible."
But Delory points out that there are ways around the limitations of agents. "If you are good enough with these tools you can always get them to do what you want them to," he says. And there's a reason that Chef and Puppet use agents; it can make automation much more responsive.
"With agents you have more code which could be buggy, but Ansible isn't capable of the speeds that you get with an agent system," says Rusev. "If there is something that I need to interact with on a daily basis then I prefer to use a system with an agent as it is snappier."
He adds that Ansible performance issues become more noticeable when dealing with more than about 100 hosts. "If you have 100 or 500 of them then perhaps you should use Puppet or Chef. At some scales Ansible becomes problematic because it consumes too much memory."
What all this comes down to is that Ansible is the darling of devops because it's easy to learn and use, it's built on Python, support is credible, and its agentless architecture makes it easy to use to control more than just servers.
The downside of choosing Ansible is that it may not scale as well as Chef or Puppet, it may lack performance — especially in bigger deployments — and the support offerings may still be a little way behind its competitors.
For that reason Delory is convinced that many organizations will continue to use Chef and Puppet alongside Ansible. "Don't assume that you can standardize on one tool or another. Many organizations use Chef and Puppet and Ansible, all for different tasks. No matter which tool you pick, you will have some people saying that you picked the wrong one."
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.