

Puppet versus Chef: Why Puppet wins - cemerick
http://bitfieldconsulting.com/puppet-vs-chef

======
zacharypinter
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

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

~~~
dlgtho
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...](http://stochasticresonance.wordpress.com/2010/01/20/puppet-
chef-dependencies-and-worldviews/)

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

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

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

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

~~~
holoway
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.

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

