CYCLONEPROJECT - Fotolia
Looking for something else?
Chef and Puppet are, for many, synonymous with the concept of automating the development and operational deployment (DevOps) of applications. The two products are the most popular in the space, have the widest support among equipment and software providers, and have set the standard for features. They're also both changing, and the drivers for the changes as well as the changes themselves are important to anyone who deploys applications. That's particularly true because Chef and Puppet also embody radically different architectures, so their evolution offers guidance on the benefits of each approach.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Not everything about Chef and Puppet is different. Like all Agile DevOps tools, they have evolved from the operating system scripting that's been around for many decades. The scripts automate critical deployment and configuration tasks to reduce operations effort and errors. As applications became distributed and required coordinated actions across many systems, both Chef and Puppet adopted a client/server model.
Chef and Puppet: From dev to ops
The difference between Chef and Puppet is usually described as the difference between a "declarative" (Puppet) and an "imperative" (Chef) approach -- Puppet describes the desired state of a deployment and manages how to get there from the current state, while Chef describes the specific steps needed to do something. In practice, the Chef approach has tended to appeal to developers (the "Dev" side of DevOps) and Puppet to operations (the "Ops" side). Programmers comfortable with writing code are comfortable writing Chef "Recipes," and operations types want to focus on describing what the deployment should look like.
The evolution of both Chef and Puppet is being driven by two application trends that impact both development and operations -- the desire for continuous delivery of applications that gracefully manages even significant changes in applications or components, and the need to support emerging public, private and hybrid cloud architectures.
Accommodating the cloud is a fairly simple enhancement for the two products, and both have explicit cloud partnerships. Both Chef and Puppet have long been based on the notion of repositories of DevOps elements that can be reused, largely because this is the model needed for modern distributed multi-component applications. The modularization of components has been extended by both Chef and Puppet to allow for modular definition and assembly of hosting resources. This facilitates the support for DevOps across multiple clouds, hybrid clouds and cloud/data center environments.
Continuous delivery presents a more complicated issue because it tends to both extend the scope of DevOps into development and application lifecycle management and blur the boundaries between development and operations. Application change management is an essential part of continuous delivery, and instead of having a clean handoff between development and operations, continuous delivery creates a dynamic interplay through all the phases of development and ALM. Chef and Puppet have responded to this in different ways, as their different approaches suggest they'd have to, but in responding, they are actually converging in many ways.
Chef moves beyond development
Chef has introduced Chef Delivery, which is a major departure from its developer-centric approach. Chef Delivery extends developer support to include code base management, version control, development collaboration control and development pipelining. It then extends this workflow into operations, so Chef Delivery is a completely integrated continuous delivery process controller. Recipes and cookbooks now support integration of deployment analytics, which can make Chef respond to application conditions by invoking recipes and enhances operations integration with the overall workflow.
The combination of Chef Delivery and an increased reliance on cookbooks has the effect of creating a higher-level model of application development and deployment that, for operations people in particular, starts to resemble a declarative model. If a recipe or cookbook describes all the DevOps sequences needed to handle all application events, it looks a lot like a declarative desired-state description, and it's a lot more operations-friendly. For some, it's become Puppet-like but without losing the development process management Chef is famous for.
Puppet hasn't been idle, though. Integrated analytics and event-handling are intrinsic to a declarative DevOps model because it's these things that have to signal the need to restore an application to the "declared" state. Puppet thus has the operations side of continuous delivery handled; they needed more on the development side. The Code Manager provides Puppet with complete management of the development/change cycle and also integrates that cycle with the rest of the ALM-DevOps flow into operations and deployment.
Puppet's Node Manager takes advantage of the inherent independence from details that declarative modeling offers. Node managers handle abstractions of hosting and connection capability, making it easier to develop support for a new cloud service or stack, and even providing the ability to support software-defined networking. The notion of making resources and code almost equivalent follows the company's "infrastructure as code" model. Project Blueshift extends basic deployment to full lifecycle management and includes built-in capabilities to manage a diverse collection of infrastructure as well as development of community partnerships to create new models for new infrastructure as it emerges.
The future of Chef and Puppet
The sum of these changes, and in particular the need for both Chef and Puppet to respond to common drivers of continuous delivery and the cloud, has elevated Chef and made Puppet more programmable, which is what converges the two products. It's fair to say that the popular characterization of their differences as "declarative/imperative" is now simplistic. Most users will be able to get to the same place with either product.
Who wins in the long term? Puppet is the current market leader, and its approach fits the modern concept of "intent models" of applications and services. If microservice composition of applications is the way of the future, Puppet may be able to get there faster. But Chef still provides more direct support for custom development of applications, and organizations with a lot of in-house development will find its integrated ALM and continuous delivery features responsive and flexible.
We're moving to a new age of DevOps, driven not only by continuous delivery and the cloud but by microservices and "compositional programming." The future won't decide between these two leading DevOps contenders, and it's already creating new competitors. The good news is that DevOps overall is aligning better with end-to-end application development and deployment, to the benefit of users.
Learn how to automate cloud deployments with Chef and Puppet
How to make the most out of DevOps tools in the cloud
Ten effective DevOps tools to compliment Chef and Puppet
Dig Deeper on Java DevOps
Tom Nolle asks:
What other tools, besides Chef and Puppet, do you use for automation and deployment?
1 ResponseJoin the Discussion