Puppet versus Chef: Why Puppet wins

Chef still feels like a set of disconnected tools waiting for somebody to integrate them nicely. The codebase is rather volatile (coming back to it after a few months required a lot of extra work) and the documentation right now is definitely poor.<p>That said, I think Chef has a lot of potential. It's just waiting for a solution that brings it all together. I'm highly looking forward to the upcoming opscode-managed Chef server. I'd like to see something like Heroku, where deployment is simple and easy, but is based on community-provided recipes (instead of Heroku-provided addons) and is closer to a fixed monthly cost (to provide the chef server) instead of a per-server-resource cost (dynos).<p>As for the article, as other haves stated, it largely talks about how Puppet is more established. The only points that matter to me are #3 and #9. #3 seems to be a direct result of Chef's entry into the market and the value of #9 seems arguable.<p>So, to summarize:<p>* Puppet is definitely more established and better documented<p>* Chef is not there yet, but has (in my opinion) more potential for the future

This basically states that Puppet is more established, which is an important point, but not exactly a conclusive "win" for everyone.<p>Unless I misunderstand #9 ("explicit dependency management"), Chef does indeed have this. It has resources that can both "listen" and "notify," just like in the Puppet example given, and things are executed in dependency order unless execution is specified as "immediate."<p>I agree with the point about Chef's Rails-oriented deployment. It's a little frustrating having to negate the default Rails settings while doing a PHP deployment.<p>To me, the major downsides to Chef are quirks/instability as changes are made during active development, and somewhat sketchy documentation in places. Still a great system though.<p>(Also: check out the reply from Adam Jacob, lead dev of Chef, in the comments. I noticed this after posting here.)

Caveat: I've used Puppet in production (and been very happy with the results), but only looked at Chef.<p>From a quick survey of the article, it missed the #1 advantage of Puppet, though the comments hit it: Puppet is declarative, which is fundamentally the right answer for this kind of problem space.<p>The flip side though, is that Chef (being mostly imperative) is easier for many people to get started with. I think this will help it gain share, in spite of the above. I might even pick it up myself, depending on the problems at hand.

6 of the 10 reasons are variants of "puppet has more adoption." I got that after the first couple, thanks!

Be sure to read the response from the lead dev of Chef here: <a href="http://bitfieldconsulting.com/puppet-vs-chef#comment-19" rel="nofollow">http://bitfieldconsulting.com/puppet-vs-chef#comment-19</a>

I honestly didnt know Puppet had such widespread adoption. The tech buzz always seems to favor Chef which is why I have more exposure to it.<p>Puppet does seem to have much much better docs on their homepage. However Chef is way more reusable. The chef recipe system is very powerful, and the fact that it uses ruby means its much more reusable using standard ruby practices (inheritance, modules, etc).<p>Sometimes its much better to be a newer technology as you can really solve some of the core issues of the preceding technology.

We manage around 200 servers with puppet.Our system administrators aren't programming savvy. It's much harder to write chef recipes, while puppet's DSL allows them to write pretty concise and clear recipes. And explicit dependencies are very helpful here, we can't imaging our life without those. It is much harder to break thing when there are several people working on one recipe/manifest.