Ansible vs. Puppet: Declarative DevOps tools square off

Speak Puppet's language

Puppet is one of the original DevOps giants and a leader in declarative DevOps. Puppet Enterprise is a commercially supported offering, and the company has four additional products, plus one in beta: Discovery for real-time inventory; Pipelines for CI/CD to servers, virtual machines and containers; Container Registry; Continuous Delivery for Puppet Enterprise; and Insights, which tracks various DevOps metrics and has not yet been released. These products expand Puppet's scope to virtually every aspect of configuration management and deployment.

Puppet uses a master/agent architecture, with an agent process that runs in each node that hosts applications. This agent gives Puppet users complete control over the deployment process in real time and at an extremely granular level. Of the declarative DevOps tools in the market, industry professionals acknowledge that Puppet offers the greatest management of configuration and the application lifecycle. The agent approach also helps Puppet scale to large deployments with limited performance impact.

Puppet uses a domain-specific language for its declarations. This specialized language requires expertise from seasoned Puppet users, but this level of control over the language enables Puppet to check the syntax of its users' work, which reduces the number of times that a small mistake creates a runtime problem.

Additionally, Puppet Tasks add a level of prescriptive, or scriptlike, control to the overall declarative Puppet model. Users can make quick changes to nodes, including configuration changes or even restarts, outside the declarative framework with Puppet Tasks. Many users report that this feature makes it easy for operations folks to do what they need to do directly, without trying to force a declarative system to make changes for them.

Puppet's rich feature set can apply to almost any software deployment, testing and lifecycle management task. To make things easier, Puppet users can contribute modules to Puppet Forge, the largest inventory in the declarative DevOps space. While users like the modules, they might require some customization to fit individual deployment and testing scenarios. But, even with the modules, Puppet comes with a steep learning curve, and it seems biased toward systems administrators and operations professionals.

Go agentless with Ansible

Ansible is a relative newcomer in declarative DevOps. Ansible doesn't use an agent, which makes it easier to adopt and deploy, but also limits node management. A large number of Ansible users in the software quality space find those limitations minimal in technical terms. Plus, they like Ansible's simpler framework compared to other configuration management and automation tools.

Agentless Ansible gives the user control over any node that accepts Secure Shell (SSH) connections and runs Python. You can control nodes from anywhere that has the proper SSH keys and access to the Ansible inventory and tools. There's no need for a central server, though most users adopt a centralized management scheme to avoid control issues. Ansible Tower provides a high-level management view of automation tasks and infrastructure, but it also integrates Ansible orchestration with control across users and software activities. Tower should be an essential part of any Ansible deployment aimed at software quality.

Ansible manages orchestration with playbooks run by an automation engine, which controls the hosts and network connectivity. A playbook is a set of YAML statements, a standard declarative language rather than a proprietary one. You can create playbooks with any tool designed to author YAML statements.

Playbook tasks execute in Ansible nodes by deploying modules remotely via SSH to them. Each task represents steps toward achieving a goal state for the node and its application components. These tasks execute remotely, and then Ansible removes the module; in effect, the modules are a transient process that bootstraps the real operation of the node. A user also can deploy command modules to provide direct control, but these operate outside the goal state-oriented declarative framework.

Modules come from various sources. Users can develop them or rely on Ansible's library. And there are also third-party elements available on the Ansible Galaxy portal. All the heavy lifting in Ansible is done via modules. So, obey the basic design principles of these modules, and integrate them properly with playbooks.

An inventory tracks Ansible nodes and typically defines them by their overall mission, such as a web server. You can also apply roles to groups of modules to simplify the configuration management process considerably.

The battleground

When it comes to Ansible vs. Puppet, the two vendors take different approaches, but both center on what most organizations want: a focus on goal states rather than on the steps needed to achieve them. However, declarative approaches depend on two things: the proper software steps to attain that goal state and an easily understood framework. Without those two elements, declarative DevOps will fail. So, these two points decide the winner.

Puppet provides the sheer power to address a panoply of deployment environments and application and node conditions. Puppet has been around longer and provides the largest library of predefined tools and components available to users. When DevOps first emerged, when deployment options were widely variable, these characteristics made Puppet attractive to many users. Puppet's configuration management features, in particular, are simply great.

But that power also makes Puppet harder to learn and work with. Almost every user review says the same thing: Ansible is easier to use than Puppet. Almost any IT professional can use Ansible; the playbooks and modules are human-readable and easily understood. With Ansible, it's possible to divide deployment, testing and operations tasks in any way needed to suit organizational requirements and compliance policies.

Ansible enables software quality pros to provision infrastructure and deploy complex multicomponent applications that have to cross boundaries between data center and cloud environments. With Ansible, it's easy to provision infrastructure and then deploy in what feels like a single step or process. Software quality assurance is most effective when it focuses on the mission of software deployment, and users think Ansible has that advantage.

The winner

It's a tough call on Ansible vs. Puppet. You can do more with Puppet, but it's challenging to use. Ansible is simpler, but there are tasks that are simply beyond the product, unless you do a lot of module customization.

The scope of software quality assurance is the deciding factor here, if narrowly. Modern software quality is an overlay upon activities from development through testing to deployment and operations management. There is a single goal but not a single organization responsible for fulfilling that goal.

With software quality in mind, Ansible wins. It harnesses the discrete organizations and individuals across that whole activity range and provides a central software quality approach.