Software configuration management is hard. It’s a little bit easier if you have software that removes some of the load. Unfortunately, configuration management isn’t just a nail for which you simply choose your hammer of preference.
Which hammer you’re trained to use can dictate the nails you can see. One way or another, you can’t solve a hard problem like configuration management unless you’re willing to learn the skills you need to become a good programmer. And sometimes you can’t learn those skills — unless you choose which direction your company is going to go.
In this metaphor, Chef and Puppet are our hammers. They’re the two leading configuration management software tools (hammers) on the market, but how they handle change integration, scaling, and test rollouts (nails) differs. You and your company should know how they differ before you choose which one you’ll use.
The most common characterization is that Chef is preferable for developers, and Puppet for sysadmins. Either way, both programs rely on IT staff learning and using new languages (scripting and declarative) and tools that affect configuration changes. The whole kit and caboodle of both will come with modules, conditional logic, variables, support for functions & reusable code, and the rest of it. It’s a tough choice!
Know what you need your Configuration Management Tool to do
Software configuration management is a footrace with two major hurdles: Revision control and baselines. SCM can figure out what was changed and who changed it when something goes wrong (…and something will go wrong). When something goes right (…that happens sometimes too), SCM should figure out what’s working so well and how to repeat it across the entire enterprise.
Generally speaking, SCMs define distinct configurations for all hosts and then perform continuous checks that confirm if the configuration is in place. When scaling up or scaling down the numbers of machines being used, SCMs dynamically assign resources. When working with multiple, geographically separated machines in a wide network, software configuration management tools provide control of the entire network — enabling an automatic propagation of one centralized change.
But different companies handle their networks differently. So knowing and understanding what your company or team needs from its configuration management tool is the first step to choosing Chef or Puppet. What’s most important for your servers?
One thing they share in common is that Puppet and Chef both use Pull Configuration. Pull Configuration Management systems are distinguished by the agents or slaves polling the central server or master at regular intervals. When the slaves detect a change, they pull the configurations. Also, Puppet and Chef both have a master-slave architecture.
A difference is that Chef has an extra component called Workstation. Workstation tests all configuration before it pushes them to the main server. This helps with safer and faster rollouts to upgrades and changes. Also, since Chef is compatible with most cloud platforms, it’s frequently used for provisioning infrastructure on the cloud.
Consider the DevOps culture along with it
A major difference between Chef and Puppet is that Chef usually comes part & parcel with DevOps. DevOps is a cultural and professional movement. DevOps IT personnel are trained in specific IT skill sets, but the entire DevOps culture is a workplace shift that focuses on faster, more streamlined communication between team members and more egalitarian reward structures.
Chef and DevOps are meant to coexist to build highly responsive organizations. That being said, it can be a tough shift for a company. DevOps companies are traditionally oriented to creating high-velocity, quick turnaround products and network scalability with widespread change.
Think About the Chef Way
There are a handful of important ways Chef is different from Puppet. First, Ruby is the configuration language for Chef, not a custom language (like Puppet) – so if you know Ruby, Chef can be easy as pie. Chef is Apache-licensed and all contributors are licensed, making it safe to include in your software.
Chef isn’t designed to be the canonical representation of your infrastructure, but instead to expose certain parts of your infrastructure. It’s possible to do that because Chef was designed to integrate with other tools, or at least to make that integration as simple as possible. And, like we mentioned, the DevOps culture usually comes with Chef.
Consider a slower, safer, Puppet way
The biggest thing to know about Puppet is that it uses its own domain-specific language (DSL), a computer language specialized to Puppet. Puppet is mature, widely deployed and has a slightly bigger, more established user community. Many experts claim Puppet is preferable for system administrators, citing Chef’s tools to be better suited for creative developers and high-speed network changes.
Rich Morrow, the author of a VB Insight report contrasting the two said, “Whereas Chef tries to provide more power to the user, Puppet puts safety rails around them.”
That difference is obvious when you look at Puppet’s strongest selling points:
- Get a log message every time anything happens via your automation;
- Simulate changes to see what would happen; audit what you’re managing and how it’s related (get a list of every resource being managed on a given host and any dependencies);
- send data to clients rather than code;
- Fully-functioning server on-premises, or even controlled by you in a public cloud.
The Final Verdict
Puppet and Chef lead the industry of software configuration management. If you’re looking for a fast, dynamic, developer-driven, and cultural shift for your company, Chef may be the right choice for you. If instead, you prefer a more sober, safer, structured software, Puppet is likely a better fit.
Both are incredibly powerful, robust, and well-established, and the skills needed to implement Chef or Puppet are yours for the taking!