Today’s sys admin and devops professionals have to manage, on average, a much larger number of servers hosting a much larger number of applications, than their counterparts from as recently as the 90’s. Blame this on the exponential growth on computing for organizations, coupled with the emergence of new technologies such as virtualization and cloud computing.
Thus tools like Puppet and Ansible are fast becoming essential components for managing a large number of servers, like in a data center. They are commonly called Configuration Management (CM) and Remote Execution (RE) tools. These mega-useful apps allow the admin, for instance, to execute an action on several servers simultaneously, deploy multiple apps with a single click, and generally make it much easier to configure and maintain dozens, hundreds, or even thousands of servers.
Puppet is the big kahuna of the CM market. It enjoys the largest market share and has been around for the longest time, since 2005, which for CM tools is like being around since the dawn of mankind. Several big-name clients run their data centers using Puppet - Google, Reddit, Dell, PayPal, Oracle, Los Alamos Labs, and Stanford University; having such clients on board always lends a certain level of credibility to a product. Puppet also boasts the most mature interface and runs on all the major operating systems – Linux, Windows, Unix and even Mac OS X. Following the model set up by the various Linux versions, it is an open-source app (developed using Ruby), but there is also a large, well-established support and sponsor company called PuppetLabs to offer professional support and a commercial enterprise version of the software. Puppet also offers a simple installation routine and several tools for tasks such as rapid deployment to client servers. There is a Ruby-based CLI in addition to the GUI; actually for most advanced tasks you will most likely have to depend on the CLI, with the GUI being a viewing, management and monitoring interface. This implies that in addition to the sysadmin work, you also have to learn Ruby.
At this point you may be thinking: “All this sounds great! Are there any cons, or can I go purchase Puppet right now?” Well, the buzz in CM discussion forums is that Puppet, like many other software giants, has become a victim of its own success and size. ‘Nimble’ and ‘agile’ aren’t words that can be used to describe Puppet – stuff like reported bugs take too long to fix and ignoring new feature requests. There is also some grumbling about PuppetLabs aggressively pushing its customers towards adopting the commercial version. And lastly, although Puppet supports both pure Ruby as well as its customized DSL on the CLI, the Ruby-only support is being deprecated. This is bad news for those who had only learnt Ruby and not the in-house DSL.
Ansible is a much smaller competitor to Puppet. First released in early 2012, it is also an open-source supported by a parent company – in this case AnsibleWorks. It was developed in Python, not Ruby, which makes it spiritually closer to Salt (another new-ish CM tool) than Puppet. The other advantage of Python is that it is inbuilt into most Unix and Linux deployments nowadays, so getting up and running is quicker. Ansible’s unique selling proposition is its lightweight and quick deployment. In fact it does not even use deployable agents for master-client communication; instead all functions are performed over SSH. For those configurations that don’t support root SSH, Ansible can ‘sudo’ as root. Ansible can be run from the CLI without the use of configuration files for simple tasks, such as making sure a service is running, or to trigger updates and reboots. For more complex tasks, Ansible configuration is handled via YAML syntax in configuration files called playbooks. Ansible commands can be written in almost any programming language and distributed as universal JSON modules, which is clearly a benefit over having to choose a single language.
The Ansible GUI is not as developed as Puppet’s. It’s actually distinct from the CLI, so the two must be regularly synced to show the same data. Ansible’s also a newer product and can’t offer the same level of comfort that a much bigger company like Puppet can. Plus, it does not run on Windows or Network Devices as Puppet can. Overall, it seems many currently see Ansible as useful for small, quick or temporary deployments (like managing a set of web servers for a one-off project) however many more companies are deploying Ansible for larger data center deployments. Ansible and the enthusiastic community are of course working hard to increase this early success – by increasing the number of supported devices, improving the GUI, and so on.
So should you choose Ansible or Puppet? There is no easy answer for this – it depends on your needs. If you need a new pair of shoes, what type of shoes should you buy? Any pair will protect your feet while walking, which is the basic premise of shoes. But still, a pair of loafers is not as good at the gym as a pair of sneakers, and are not as appropriate for a formal interview as black leather shoes.
The table below summarizes some pros and cons for you – so you can choose between Puppet loafers and Ansible sneakers.
Support for all major OS’s
Slow-ish to respond and address customer concerns
Ruby-based, performance questionable compared to Python-based CM tools
Soon all customers must learn the Puppet DSL
Excellent performance, agent-less install and deploy