Puppet vs Chef, pro and contra from users and use cases [closed]

To be honest, I think this comes down to simple viewpoint: Chef seems more of an imperative, programmatic solution, the usage of ruby as the language instantly makes me hope somebody ported it to python, as is the way of the world with all of ruby's ideas.

That's not what you want for this sort of thing though. You want to speak to the void where the system will be and declare:

"Upon port 80 summon from the north the daemon named nginx. His task is to serve."

"A user should exist, his name should be chiggsy and he should be one of the mighty in the group of wheel,"

"Raise up a wall of fire, thin in the places 80,443,8080"

And so on, although perhaps in language less flowery.

Puppet supports that paradigm better IMO. I'd have used either one, I had no preference but when it came down to it, declarative suited me better.

Puppet.

I've written a detailed comparison of Chef vs Puppet here: Puppet vs Chef: 10 reasons why Puppet wins. Although it doesn't include use cases, I hope it provides some useful starting points for people wondering which tool to choose for their infrastructure automation.

Sorry about the verbosity. Use the tool that makes it's easy to get your job done. That's the point of automation, right?

History: I have used puppet in past gigs and last month I spent about a week trying to get used to chef to see if I would make the switch at my new gig.

I didn't leap.

Jargon: One unfortunate problem with both of these systems is the jargon overload. (recipes, templates, nodes, roles, attributes, providers) It goes on and on. I found Chef took it a step farther. (Knife, Shef, etc.)

Code Maturity: Suffice to say that I found Chef just a little too raw. It feels a lot like what puppet felt like in the .21/.22 timeframe 3-4 years ago. There's a lot of flux going on.

Not to say that hasn't happened in puppet either. (I re-discovered many great features in puppet that have only surfaced in the last few years. -- regex matching!)

Ruby: I didn't like all the ruby overload in Chef. (you need gem and rake before you can even get started) You can use ruby to solve complex problems in puppet a'la facter, but you don't have to if you don't want to.

Complexity: I didn't like the GUI focus on chef. I realize it's pretty and the puppet has a web interface in the works as an add on, but I feel that should be more decoupled.

Chef has a much more complex architecture. It might scale better, but there are lots of potential points of failure.
http://wiki.opscode.com/display/chef/Architecture

Chef needs couchdb, rabbitmq and solr in addition to the API server and web interface.

I just want a simple client/server interface that doesn't need a MVC framework on top of it and a complex data store behind it.

Puppet is a lot simpler in that department. (not to say there aren't lots of add ons to make it messier)

Getting work done: In the end, I went with what I knew. After spending a week of side hacking and barely being able to get basics done with Chef, I was able to go back to puppet and pound out my basic needs in a few hours. (package management, user management, config file templates)

Caveat about Modules: Puppet has a recent shift to using "modules" which are contributed by third parties. I didn't end up using these and I found a wide range in their quality. Be sure to peek under the covers and see what and how they are working before you dig in to these.

Here is a opinion: We have tried all of them in our company and we prefere puppet. Simply because it is easy to use.