Application development is changing rapidly under Agile development/continuous delivery pressure. Deployment is also changing as components and services become the deployment units and virtual infrastructure becomes the deployment target. Is it surprising that DevOps tooling is changing too? Hardly; so the question is whether new or second-generation tools are better than the evolved versions of the market-leading tools Chef and Puppet. To answer that, you have to define a standard against which the new and old can be measured.
Early DevOps tooling evolved from operating system scripting tools, and their focus was on configuration management, meaning the preparation of servers to host applications and components. The presumption was that "hosting" something meant customizing the hosting environment to supply the resources and connectivity needed.
Chef, called an "imperative" or step-based DevOps model, retains the structural flavor of configuration management. Puppet, the "declarative" competitor, is based on end-state models of what a configuration should look like, not how to get there. Both of these products go back about a decade.
Moving DevOps tooling to the cloud
The transformational factor in DevOps evolution is arguably the shift to virtualization and the cloud. Virtualization in any form creates an intermediary element -- a container or virtual machine -- on which applications and components are hosted, and which is then mapped to infrastructure. This two-step process means you have a general need to host a virtual element on varied, real infrastructure and to then host applications in what appear to be fixed virtual elements. This shift of direction, which is perhaps five years old, would seem to be both a driver for the changes to the first DevOps tools and the opening for a next-generation DevOps product.
Three products epitomize second-generation DevOps -- Ansible, Juju and SaltStack. All of these use a remote node and parallel execution model that's also used by both Chef and Puppet. They also support the new concept of a virtual abstraction as a deployment intermediary, and users generally say that the two newer products, Ansible and SaltStack, are more "natively" virtualization driven. You could say that both are cloud-driven, cloud-ready and accommodated to more than just the cloud. The difference between them lies in how they perceive the cloud.
The learning curve for Ansible is far shorter than any other popular competitive product.
Ansible is arguably a kind of "populist DevOps," and even their website tagline says that it's "Automation for Everyone." Ansible assumes that the cloud will drive greater DevOps dependence by driving DevOps use down market. Most who have tried Ansible say that it's much easier to deploy and use than either Chef or Puppet and that its tools (like its "best practices" guides) seem designed to take an organization with little or no DevOps exposure and make them a DevOps business. It has a modular structure and users either adopt community "modules" that work for them or build their own. Either way, modules are easily written and read with a text editor.
Juju is a cloud's eye view of DevOps. It provides less in the way of configuration management than it does in support of application deployment onto those virtual intermediary elements that create the DevOps generational boundary. In fact, some in the Juju community advocate using Juju above a Chef/Puppet configuration management model.
Juju is strongly linked to Ubuntu Linux, too, and so many feel it's too specific for hybrid clouds and generalized servers. These Ubuntu/Linux associations are not rigid, though, and Juju is evolving to be more generalized, just as Chef and Puppet are evolving to support virtual intermediary deployment models.
SaltStack is perhaps an automation for everything model. Their primary product view is one that links IT operations, cloud operations and DevOps in a single model, which is clearly a mission/technical view of the DevOps problem. The concept of having three separate "Ops" dimensions united in a common tool tracks modern trends in development and deployment quite well. SaltStack also has multiple dimensions in its modeling -- "State" modules represent declarative end-state goals, much like what Puppet supports, and "Execution" modules represent coded scripts, much like Chef.
Alert-based DevOps tooling
If complex orchestration is the goal, SaltStack provides support through a combination of "events" to signal conditions and "reactors" to respond to them. This is similar to the approach taken by both Chef and Puppet. Ansible is more policy driven in its orchestration, which is easier for non-programmers to understand, but less flexible in coordinating activity between application and resource layers and across multiple systems. Juju, focusing more on the application to virtual abstraction deployment, is less reliant on complex orchestration and events.
If you are an SMB looking at DevOps for the first time or a cloud-driven activity inside a larger enterprise and you have limited technical expertise in DevOps, Ansible is a strong choice. The learning curve for Ansible is far shorter than any other popular competitive product and the support community is quick to respond to questions. Ansible is "down-market DevOps" in a very real sense.
SaltStack aims at companies whose current DevOps evolution has perhaps become too complicated because of the large number of development and infrastructure changes the last four years have generated. Some of these companies have created unwieldy and illogical DevOps libraries using Chef or Puppet and are looking for something that is organized for the future and that addresses big enterprise issues like performance, security and governance.
If you plan to move most or all of your applications to the cloud or if you want to manage public cloud deployments independent of data center practices, then Juju is a strong option. Line organizations, with some community or technical support, can use Juju for DevOps, and it's possible to even orchestrate hybrid clouds if configuration management of the data center resources is handled elsewhere.
The first-generation tools, like Chef and Puppet, are still leading the market, and the size of the user community for these tools makes it hard to ignore them, particularly for companies with complex development and deployment needs. But don't ignore the second-generation tools either; they may frame the future of DevOps.
Next Steps
Putting together a strong DevOps team
How to adopt an effective DevOps strategy
Integrating DevOps into your cloud deployments
Dig Deeper on DevOps-driven, cloud-native app development
