Puppet versus Chef: Why Puppet wins

http://bitfieldconsulting.com/puppet-vs-chef

by cemerick • 16 years ago

26 12 16 years ago

jbellis• 16 years ago

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

jpcx01• 16 years ago

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.

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).

Sometimes its much better to be a newer technology as you can really solve some of the core issues of the preceding technology.

dnsworks• 16 years ago

Luke got a good amount of adoption early on. Chef actually only started as a response to Puppet about two years ago when Opscode's original company, HJK Solutions decided they didn't want to have to pay for Puppet support.

The main advantage to opscode I see is that Chef does a better job of marketing and hype generation.

dlgtho3• 16 years ago

That's true about hype and marketing. Including spamming #puppet channel trying to divert people to chef when they come asking for help.

holoway• 16 years ago

As one of the founders of Opscode, and of Chef, it's crazy to say that the reason we started Chef was because we didn't want to buy a support contract.

We have no beef with Puppet - from our experience building fully automated infrastructures at scale, it wasn't the tool we wanted (and it still isn't,) so we built Chef - the tool we wanted. It turns out it's also the tool lots of other people wanted, and we're incredibly proud of it.

There is nothing dirty here, no matter how much the internet wishes it to be so.

pie• 16 years ago

This basically states that Puppet is more established, which is an important point, but not exactly a conclusive "win" for everyone.

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."

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.

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.

(Also: check out the reply from Adam Jacob, lead dev of Chef, in the comments. I noticed this after posting here.)

dlgtho3• 16 years ago

What author meant, i think, is that "Chef manages resources in the order they are specified." while Puppet encourages usage of "require" parameter to explicitly define the dependency. He does state that it is possible in chef, also providing link that explains the difference. Here is the link if you missed it http://stochasticresonance.wordpress.com/2010/01/20/puppet-c...

zacharypinter• 16 years ago

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.

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).

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.

So, to summarize:

* Puppet is definitely more established and better documented

* Chef is not there yet, but has (in my opinion) more potential for the future

kylecordes• 16 years ago

Caveat: I've used Puppet in production (and been very happy with the results), but only looked at Chef.

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.

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.

Vitaly• 16 years ago

Shadow puppet http://github.com/railsmachine/shadow_puppet is a Ruby DLS for Puppet. it allows you to have the best of both worlds. you still 'declare' your resources but you can imperatively build those declarations.

joevandyk• 16 years ago

Be sure to read the response from the lead dev of Chef here: http://bitfieldconsulting.com/puppet-vs-chef#comment-19

dlgtho3• 16 years ago

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.

Puppet versus Chef: Why Puppet wins

Related Stories