Chef and Puppet
Puppet is a powerful enterprise-grade configuration management tool. Both Chef and Puppet help development and operations teams manage applications and infrastructure. However they have important differences you should understand when evaluating which one is right for you.
Platform scope
Puppet’s focus on configuration management is a good match for organizations looking to get started with automation of basic infrastructure tasks. Puppet is an older technology than Chef and its more established roots speak well to the needs of traditional infrastructure operators. That focus makes Puppet appealing to organizations exploring solutions for infrastructure automation concerns.
Chef takes the position that automation needs to be ubiquitous. Stretching beyond infrastructure automation, the Chef Automate platform also includes solutions for automating compliance assurance and for automating modern applications such as those found in microservice architectures. Chef works exceptionally well for infrastructure automation, but our customers typically want to move forward and solve additional problems with automation once the basic infrastructure concerns are covered.
Scalability
As infrastructures continue to grow, it’s important to consider the scalability and performance of distributed automation. Puppet implements a command-and-control model in standard mode that orients around enforcement of policy from a centralized master. While that model makes Puppet a good choice for traditional management styles it also means that one node (or set of nodes) is responsible for computing the desired state of each machine in your fleet and controlling its actions from one place. A command-and-control approach works well at smaller scales, but the architectural design inherently lends itself to bottlenecks.
Chef designs its products around distributed systems principles. While Chef does contain a central artifact repository, it interacts with each machine in your fleet as an autonomous actor that computes its own settings and manages its own needs. By distributing that computational burden to the edge, Chef scales remarkably well. Chef’s largest public implementation reference is for an infrastructure consisting of over 250,000 nodes. Chef continues to focus on scaling performance in newer products like Habitat, which rely on modern distributed systems protocols to set up performant self-managing application networks.
Extensibility
Puppet uses a Ruby-based domain specific language (DSL) as a way to abstract complexity from automation engineers wishing to accomplish basic tasks. This DSL allows users to more quickly compose automation code into reusable modules that can be applied multiple use cases. In these manners, Puppet and Chef are mostly identical and they make getting started with automation approachable. However, Puppet implements its own non-standard custom programming language with restrictive rules.
Chef also has a DSL that provides an easy to approach interface for managing basic configuration tasks. But when the Chef DSL is unable to account for complex scenarios, users can leverage the full power of the Ruby programming language to model appropriate solutions. That makes Chef a good choice for organizations with complex topologies or deployment needs. Several established patterns for creating custom solutions exist and many are already available through Chef’s vibrant open-source development community. You don’t need to know Ruby to use Chef, but when facing uncommon edge case scenarios it’s possible to use just enough Ruby to work your way through the most complicated tasks.
Change validation
When introducing change across a wide fleet of automated machines, the stakes are high when it comes to mitigating the potential to spread damage quickly. Puppet recognizes this need and provides a ‘no-op’ mode, or a simulation mode that determines the best guess of what might occur based on the current state of a test system. Automating infrastructure configuration frequently involves an ordered set of tasks that may do unpredictable things as part of their normal function (think: `apt-get update` or pulling the ‘latest’ set of Windows patches). We know the desired action, but we don’t entirely know the actual output that will occur. Therefore, simulation modes like ‘no-op’ must make assumptions about what may actually occur when a system introduces change.
While Chef does have a ‘dry run’ mode, Chef practitioners typically rely on built-in tooling to perform automated integration tests that determine whether a proposed change is actually destructive by applying that change to real (yet disposable — think: VMs or containers) systems. Change validation occurs on machines that have applied a proposed change and wherein operators can observe real results. This approach to real integration testing makes Chef a good choice for organizations seeking the highest degree of confidence before introducing change to production systems.
Continuous Delivery
As organizations become comfortable managing their infrastructure as code, they tend to apply software development lifecycle practices such as Continuous Delivery to their infrastructure automation. The ability to introduce change faster, safer, and more reliably provides a number of well-established competitive benefits to the business. Like Chef, Puppet can be managed via common CI/CD tools like Jenkins, Git, etc. If your organization already has investments in these areas, either choice will work well with your already established toolchain.
However, Chef believes so strongly in the need to deliver to market quickly that the Chef Automate platform includes a workflow engine to helps organizations beginning their journey with automation jumpstart their needs. The workflow features of Chef Automate may be used in a self-contained standalone mode, they may be integrated with existing tools you have in your deployment pipelines, or you can opt not to use them at all (although Chef generally recommends using some type of deployment pipeline). Chef provides options to meet you where you already are when it comes to embracing the need to deploy software quickly.
Compliance Automation
In addition to automating infrastructure with configuration management, Chef Automate includes support for automating compliance assurance. Applying system configuration is a vital concern when first provisioning applications and infrastructure. Ensuring those components don’t expose your organization to additional risk is a vital concern during the remaining lifecycle of your infrastructure and applications.
Assuring compliance requires typically requires separation of duties. To achieve this goal, Chef Automate relies on the InSpec tool. InSpec is completely separate from the chef-client and the two share no dependencies. One tool is responsible for detecting the state of compliance assurance, while the other is responsible for the implementing corrections. By separating the detect & correct portions of systems management, Chef Automate ensures organizations can meet the needs of their Information Security compliance standards.