Puppet vs. Chef, Fight!

Update: see Puppet vs. Chef en francais, not a translation but an original article inspired by this one

If you aren't yet using Puppet or Chef for managing your *nix infrastructure, you should seriously consider it. The benefits are enormous. Frankly, I don't think you __can__ manage a modern infrastructure without using Puppet, Chef, or reinventing a configuration management framework with your own custom scripts. However, you can't use both Chef and Puppet together, so which should you choose?

If you're like me, you obsess over tool choices. You agonize for weeks over these decisions. Why? Because you will end up putting a huge personal investment in the chosen tool. There isn't all that much on the relative benefits of Puppet vs. Chef besides this quora thread. Below you will find my completely subjective, non-comprehensive study of the matter. TL;DR, Chef wins but by only a narrow margin.

The Criteria

1. Community Strength
2. Leadership
3. Corporate Adoption
4. Technical Merits
5. Hands-on Experience

Community Strength

Community Size

Number of people on IRC on Sunday Oct 9th, 2011 10 AM GMT
#puppet   541 users
#chef       233 users

Mailing Lists
puppet-users  3363 members, 5961 topics
chef: 600 members, # of topics unknown

Regarding IRC, Chef seems much more U.S.-centric. It can be hard to get answers during the European workday. The situation is probably better for Asian users as they can catch the North American community when it is early evening on the West Coast of the United States. That is not true for Puppet, where you can get an answer at any time of day or night. R.I. Pienaar is based in London and seems to be on IRC at all hours. Somehow he manages to kick out awesome code and be continuously available. Further, James Turnbull doesn't seem to sleep either and is incredibly helpful.

Quality of Cookbook Sites

http://community.opscode.com/cookbooks
http://forge.puppetlabs.com/

Github Repositories:
puppet:  1622 repositories
chef:      1299 repositories

While Chef is much younger project than Puppet, it is really impressive how many cookbooks there are and their respective quality, especially when Chef is less than half the age of Puppet. From what I can tell, most people bypass the community sites and go straight to github to find their Chef cookbooks or puppet modules.

Documentation, Official and Informal

Both Puppet and Chef have excellent reference documentation. In my opinion, the Puppet docs help you get up and running much faster. Pro Puppet, by Puppet Labs engineer James Turnbull, is an awesome introduction to Puppet. I found it immensely helpful. There is a 50-page O'Reilly publication on Chef, Test-Driven Infrastructure with Chef, but it cannot match the breadth of Pro Puppet.  I have heard that O'Reilly are going to be publishing a feature-length definitive guide, scheduled to be out by the Summer of 2012.

The Chef community definitely tends more towards programmers and rubyists than systems administrators. I think that puppet meets the needs of the majority of its users so well that they never try Chef.

Leadership

We all know that leaders can make or break open-source projects. The BDFL's personality shapes the project more than the actual code. What would linux be without Linus Torvalds' stewardship? I am wary to bet against Puppet founder Luke Kanies. He is both a genius and a visionary. He reminds me a little of another Reed College alumnus. I highly recommend listening to Luke Kanies interview on DevOps Cafe. He shows himself to be very intelligent and very opinionated. My understanding is that his original motivation for creating Puppet was to make life better for the average sysadmin.

The resumes of the Opscode team are just amazing. CTO Chris Brown and co-founder Jesse Robbins were core infrastructure engineers at Amazon, the company that perhaps more than any other understands how to manage infrastructure at scale. Listen to co-founder Jesse Robbin's Interview and you will find him to be very pragmatic about infrastructure and less opinionated than Luke. His motivation was to create an open-source tool that solved the kinds of infrastructure problems he dealt with while working at Amazon.com.

On the funding side, both companies have closed substantial Series B funding rounds. We're talking more that 10 million dollars each. Both of these companies can throw a number of talented software engineers at the devops problem domain for a while to come.

Corporate Adoption

I believe that both Puppet and Opscode corporations will become extremely successful. Jesse Robbins explains this best in Virtual Strategy Magazine.

 Our primary competitor is the in-house, home-grown tooling that every systems engineer has had to cobble together to deal with their legacy environments. That’s our principal competitor. 

That's right. The biggest competitor to Chef and Puppet isn't each other but that hairball nest of Bash and Perl that holds your data center together.

Still, Puppet has an amazing customer list but Chef is also racking up wins. If Puppet Enterprise 2.0 delivers half of what its press release promises, it will be a huge success. Puppet Enterprise's integration with mcollective is particularly exciting.

I am particularly impressed that a number of companies have built their own internal provisioning tools on top of Chef, notably Rackspace Cloud Builders and Dell's Openstack team.

Technical Merits

Puppet is designed to be approachable by systems administrators. It is not necessarily written to empower rubyists. Writing Puppet manifests, at least initially, feels much like writing nagios or apache configurations. However, it starts feeling much like programming once you get beyond simple resource specification.

Chef is designed to help engineers manage the configuration of their infrastructure at scale. It does not have the same focus on easy-of-use, nor is it as opinionated as Puppet. Now let's look at a few salient features.

Syntax

Here are examples of how to create a user in first Puppet and then chef


They don't look terribly different, but now let's throw some Ruby into the mix. In the following example, I iterate through a list of users stored in a data bag


Now you should have a better sense of the difference between Puppet and Chef. Some may have a valid criticism that Chef lets you do too much by allowing you use regular Ruby. I have to admit that undisciplined use of Ruby is as dangerous if not more dangerous as perl or bash abuse. At the same time, it is quite empowering. The Chef community really needs some kind of chef-lint tool to tell you when you're doing something you shouldn't.

Debugging

I miss noop mode in puppet, though this is on the way for Chef. It is a wonderful way to see how your puppet configuration differs from what is actually on disk without actually changing anything. I have heard some refer to noop mode as "Lie to me mode" though I have yet to have it bite me in the ass. I might feel very differently if I had experienced that personally. I also liked how puppet spit out the text of rendered templates to the console. Maybe you can do this with Chef as well, but I haven't figured out how to yet.

Chef's Secret Sauce 

Chef's Data Bags are incredibly useful. They are a very nice way to feed lists of users to multiple cookbooks. Think of them as global variables for your chef-server. One the benefits of data bags is that they allow you to separate your corporate information from your cookbooks. Thus, making it easier for Chef users to open-source their cookbooks. Puppet has extlookup but that is quite a bit more limited than data bags. It looks like Puppet maybe getting something similar to data bags with Hiera.

I also have to praise the Search function. It is an extemely intuitive way to to tie together dependencies between nodes, such as between a nagios server and its clients. Puppet has a way to "export" resources but I could never get my head around how that worked.

In my experience, Chef has a more powerful read-eval-print-loop (shef) than Puppet does. I use shef quite frequently and I cannot understate its helfulness. Puppet does not have a similar repl as far as I am aware.

Server-side, Chef is much more complex but also seems to be better thought out. I love the fact that Chef uses a document-oriented database. This combines the benefits of using files to store your configuration (easy to understand) with the benefits of using a database (speed).

Hands-On

I don't believe there are many in the Puppet community that have extensively experimented with Chef before choosing Puppet. There are many in the Chef community that have worked previously with Puppet and found that it did not meet their needs.

I started working with Puppet in June of this year and quickly fell in love. I read Pro Puppet and did all the exercises. Next I set to rewriting my 400 line linux provisioning script in puppet manifests. At first it  went well but then things got more complicated. I kept tripping over the DSL's syntax and was surprised that there weren't more puppet modules in puppetforge or github. I felt that I had to learn both the Puppet DSL and Ruby to really to be effective with Puppet. I started thinking that the grass might be greener on the other side.

Two things convinced me to try out Chef. The first was the announcements by Dell and Rackspace that they had built there Openstack provisioners on top of Chef. If the people pioneering devops chose to build their platform on top of Chef, then it definitely deserved my attention. The next was Jesse Robbins' interview on DevopsCafe. He made all the action in the Chef community sound so exciting that I had to go check it out for myself.

It took me three days to get Chef Server up and running on RHEL 5.7. Next, I started writing my own cookbooks. Now I have nearly converted that linux provisioning script to a cookbook. Not counting the time it took me to set up the server, it took me roughly half the time it took with Puppet.

It was easy to get started with Puppet, but things became more complicated with time. With Chef I am having the opposite experience. Again, the single biggest drawback to Chef is that it has a steeper learning curve than Puppet. Further, most of the existing tutorials focus on the deeper concepts in Chef rather than giving novices quick gratification. To this end, I have started the "Dirty Chef" series of tutorials.

Summary

Final Scorecard
Community              --  Puppet wins
Leadership               --  Draw
Corporate Adoption --  Draw
Technical Merits      --  Chef
Hands-On                --  Chef

According to this non-scientific criteria, Chef is the better tool. In my humble opinion, Chef is technically superior. Don't buy the argument "Chef requires you to be a programmer, Puppet doesn't." While Puppet is geared towards non-programmers, it becomes regular programming once you do anything moderately complicated. That's when Puppet's DSL becomes more of a liability than an asset and where Chef really shines. Now while chef is the winner of my little bake-off, it is not without faults. Puppet has far better support for RHEL/Centos and it does have a larger, more responsive community.

Dear Puppet community, please know that I write this blog post with great ambivalence and I still love you. Jame Turnbull and R.I. Pienaar, thanks for all your help via IRC, Twitter, and the mailing list. Puppet Labs is developing a toolchain that is much larger than just the puppetmaster. This toolchain may turn out to be superior to what Opscode and its respective partners come up with.

On a final note, please know that both of these tools are good enough for configuration management and are only one part of a larger toolchain.

P.S. I will delete any comments that trash either Puppet or Chef. They are both excellent tools, built by
visionaries.

Most of the discussion related this article seems to be happening on Hacker News.