What are the right questions to ask when deciding whether to use Chef or Puppet?

I am about to start a new project which will, in part, require deploying many identical nodes of approximately three different classes:

• Data nodes, which will run sharded instances of MongoDB.
• Application nodes, which will run instances of a Ruby on Rails application and an older ASP.NET MVC application.
• Processing nodes, which will run jobs requested by the application nodes.

All the nodes will run on instances of Ubuntu 10.04, though they will have different packages installed.

I have some familiarity with Chef from previous projects, though I don't consider myself an expert. In an effort to do due diligence, I have been investigating alternative possibilities. We have a number of folks in-house who are long-time Puppet users, and they have encouraged me to take a look.

I am having trouble evaluating both choices, though. Chef and Puppet share many of the same domain terminology -- packages, resources, attributes, and so on, and they have a common history that stems from taking different approaches to the same problem. So in some sense they are very similar. But much of the comparison information I've found, like this article, is a little outdated.

If you were starting this project today, what questions would you ask yourself to decide whether you should use Chef or Puppet for configuration management? (Note: I don't want answer to the question "Should I use Chef or Puppet?")

Both Puppet and Chef can do what you want just fine. Your best is going to be to start doing what you're trying to do and decide which tool you like the best. I think the big questions you have to have to ask is:

Do you want a DSL? - Chef recipes are written in ruby, puppet has a DSL. Whether a DSL is good or a bad choice is one of the biggest differences between chef and puppet. The link you posted to bitfield consulting's comparison has some good comments about this you should read if you haven't already. I also found this blog post useful, make sure you read the comments too.

Do you know ruby? - If you don't know ruby, getting started with chef can be harder or require a larger investment of time since you need to learn a new language. Puppet has its own language which is easy to get started with. Starting with puppet 2.6, manifests can be written in ruby too.

At the Open Source Bridge in 2009, they had a panel of the authors and representatives of chef, puppet, bcfg2, cfengine, and automateit which you can watch on bliptv which has 1.75 hours of discussion about configuration management utilities.

Opscode/Chef talks about the difference between it and puppet in their FAQ as well.

I think your not knowing the right questions to ask might stem from you not having too much experience working with either of them, once you start using them you'll start seeing the differences between them. I'd suggest coming with some real life problems you will solve with chef or puppet, then start trying to solve them and see what you like/dislike about them. With Opscode/Chef, they offer a hosted solution that you can set up 5 nodes for free to get started.

Let me say first -- if you're not using either Puppet or Chef; there is no wrong answer. Either will be so much better than what you're doing now.

As a team lead, I made the choice for Puppet for my team. If I were a team of just myself, I would have chosen Chef instead. Here's why:

While my expertise is certainly in systems administration, my background is in programming. It's what I went to school for, and I'm no stranger to writing full applications (not just scripts). While I didn't know Ruby, I want to, and Chef would have been a great excuse to go learn both.

However, my team is full of systems administrators with little to no programming experience, aside from the occasional shell script. For them, writing a puppet module is much like writing a configuration file. It's declarative, there's no iterators, and overall it's more admin-friendly.

Teams full of developers doing sysadmin activities tend to prefer Chef. Since Puppet's DSL is declarative, order (even within individual files) doesn't matter, and that frustrates many used to more typical programming language.

I've also heard it been said many times that Chef is much more cloud-friendly than Puppet, but Puppet has made that a focus with their Puppet Enterprise product in the past year. I can't speak from experience on either products' cloud abilities.

Because of those above qualities, the stereotype (and it's often correct) is that you'll find Puppet to be more pervasive in the enterprise on physical machines, where Chef rules the startups in the cloud. There's exceptions of course, but what I've seen certainly backs the stereotype.

If it's a one-person team, then evaluate both and pick which one you like. However, if like me you have a team of people, make sure that you keep the needs of your team prioritized over any personal preferences, it will save you later when you try and get buy-in.

Full disclosure, we do not use either of these, although we evaluated them internally while trying to decide on a configuration management system. So do not consider me an expert on what either of these after all.

• How easy is it to get an instance setup?
• What setup is required on the client to get it to communicate with the server?

And so on. But you can answer these questions very easily yourself: set them up! Getting a sample up and running is a few hours of your time for each product, and considering that whatever you use this for will likely be used for a long time, the time is well worth it. Not only can you get a feel for how they handle platform specific things (i.e., Debian based and apt, RPM based and yum), but it will definitely help you get a feel for the applications.

Keep in mind, too, that all the features in the world won't make up for a difficult interface, plus, it may expose problems that are specific to your infrastructure--i.e., what happens if config files are updated in a different order than expected?

So that's my advice; Chef and Puppet are not all that difficult to get one server and one or two clients setup, and will give you first hand experience on both. Plus, if you start setting it up and realize its a huge pain, you'll already have the knowledge before committing to it.

If there are people on your project who already have experience with Puppet, then I suggest you just use Puppet.

Chef and Puppet are fairly similar, and both projects are equally high-quality. If you have access to people who already have Puppet experience, just use Puppet.

The above is definitely a good guideline, I also like to ask these general questions whenever I am considering a new third party dependency.

• What is the age of project?
• How active is the community (Mailing lists, bugs, irc etc)?
• Is good solid documentation provided with standard practices?

These are good indicators of the overall success of the project and can somewhat predict the life span.