Skip navigation.

Puppet versus Chef: 10 reasons why Puppet wins

Puppet, Chef, cfengine, and Bcfg2 are all players in the configuration management space. If you’re looking for Linux automation solutions, or server configuration management tools, the two technologies you’re most likely to come across are Puppet and Opscode Chef. They are broadly similar in architecture and solve the same kinds of problems. Puppet, from Reductive Labs, has been around longer, and has a large user base. Chef, from Opscode, has learned some of the lessons from Puppet’s development, and has a high-profile client: EngineYard.

You have an important choice to make: which system should you invest in? When you build an automated infrastructure, you will likely be working with it for some years. Once your infrastructure is already built, it’s expensive to change technologies: Puppet and Chef deployments are often large-scale, sometimes covering thousands of servers.

Chef vs. Puppet is an ongoing debate, but here are 10 advantages I believe Puppet has over Chef today.

1. Larger installed base

Put simply, almost everyone is using Puppet rather than Chef. While Chef’s web site lists only a handful of companies using it, Puppet’s has over 80 organisations including Google, Red Hat, Siemens, lots of big businesses worldwide, and several major universities including Stanford and Harvard Law School.

This means Puppet is here to stay, and makes Puppet an easier sell. When people hear it’s the same technology Google use, they figure it works. Chef deployments don’t have that advantage (yet). Devops and sysadmins often look to their colleagues and counterparts in other companies for social proof.

2. Larger developer base

Puppet is so widely used that lots of people develop for it. Puppet has many contributors to its core source code, but it has also spawned a variety of support systems and third-party add-ons specifically for Puppet, including Foreman. Popular tools create their own ecosystems.

Chef’s developer base is growing fast, but has some way to go to catch up to Puppet - and its developers are necessarily less experienced at working on it, as it is a much younger project.

3. Choice of configuration languages

The language that Puppet uses to configure servers is designed specifically for the task: it is a domain language optimised for the task of describing and linking resources such as users and files.

Chef uses an extension of the Ruby language. Ruby is a good general-purpose programming language, but it is not designed for configuration management - and learning Ruby is a lot harder than learning Puppet’s language.

Some people think that Chef’s lack of a special-purpose language is an advantage. “You get the power of Ruby for free,” they argue. Unfortunately, there are many things about Ruby that aren’t so intuitive, especially for beginners, and there is a large and complex syntax that has to be mastered.

There is experimental support in Puppet for writing your manifests in a domain language embedded in Ruby just like Chef’s. So perhaps it would be better to say that Puppet gives you the choice of using either its special-purpose language, or the general-purpose power of Ruby. I tend to agree with Chris Siebenmann that the problem with using general-purpose languages for configuration is that they sacrifice clarity for power, and it’s not a good trade.

4. Longer commercial track record

Puppet has been in commercial use for many years, and has been continually refined and improved. It has been deployed into very large infrastructures (5,000+ machines) and the performance and scalability lessons learned from these projects have fed back into Puppet’s development.

Chef is still at an early stage of development. It’s not mature enough for enterprise deployment, in my view. It does not yet support as many operating systems as Puppet, so it may not even be an option in your environment. Chef deployments do exist on multiple platforms, though, so check availability for your OS.

5. Better documentation

Puppet has a large user-maintained wiki with hundreds of pages of documentation and comprehensive references for both the language and its resource types. In addition, it’s actively discussed on several mailing lists and has a very popular IRC channel, so whatever your Puppet problem, it’s easy to find the answer. (If you’re getting started with Puppet, you might like to check out my Puppet tutorial here.)

Chef’s developers have understandably concentrated on getting it working, rather than writing extensive documentation. While there are Chef tutorials, they’re a little sketchy. There are bits and pieces scattered around, but it’s hard to find the piece of information you need.

6. Wider range of use cases

You can use both Chef and Puppet as a deployment tool. The Chef documentation seems largely aimed at users deploying Ruby on Rails applications, particularly in cloud environments - EngineYard is its main user and that’s what they do, and most of the tutorials have a similar focus. Chef’s not limited to Rails, but it’s fair to say it’s a major use case.

In contrast, Puppet is not associated with any particular language or web framework. Its users manage Rails apps, but also PHP applications, Python and Django, Mac desktops, or AIX mainframes running Oracle.

To make it clear, this is not a technical advantage of Puppet, but rather that its community, documentation and usage have a broader base. Whatever you’re trying to manage with Puppet, you’re likely to find that someone else has done the same and can help you.

7. More platform support

Puppet supports multiple platforms. Whether it’s running on OS X or on Solaris, Puppet knows the right package manager to use and the right commands to create resources. The Puppet server can run on any platform that supports Ruby, and it can run on relatively old and out-of-date OS and Ruby versions (an important consideration in many enterprise environments, which tend to be conservative about upgrading software).

Chef supports fewer platforms than Puppet, largely because it depends on recent versions of both Ruby and CouchDB. As with Puppet, though, the list of supported platforms is growing all the time. Puppet and Chef can both deploy all domains of your infrastructure, provided it’s on the supported list.

8. Doesn’t reinvent the wheel

Chef was strongly inspired by Puppet. It largely duplicates functionality that already existed in Puppet - but it doesn’t yet have all the capabilities of Puppet. If you’re already using Puppet, Chef doesn’t really offer anything new that would make it worth switching.

Of course, Puppet itself reinvented a lot of functionality that was present in earlier generations of config management software, such as cfengine. What goes around comes around.

9. Explicit dependency management

Some resources depend on other resources - things need to be done in a certain order for them to work. Chef is like a shell script: things are done in the order they’re written, and that’s all. But since there’s no way to explicitly say that one resource depends on another, the ordering of your resources in the code may be critical or it may not - there’s no way for a reader to tell by looking at the recipe. Consequently, refactoring and moving code around can be dangerous - just changing the order of resources in a text file may stop things from working.

In Puppet, dependencies are always explicit, and you can reorder your resources freely in the code without affecting the order of application. A resource in Puppet can ‘listen’ for changes to things it depends on: if the Apache config changes, that can automatically trigger an Apache restart. Conversely, resources can ‘notify’ other resources that may be interested in them. (Chef can do this too, but you’re not required to make these relationships explicit - and in my mind that’s a bad thing, though some people disagree. Andrew Clay Shafer has written thoughtfully on this distinction: Puppet, Chef, Dependencies and Worldviews).

Chef fans counter that its behaviour is deterministic: the same changes will be applied in the same order, every time. Steve Traugott and Lance Brown argue for the importance of this property in a paper called Why Order Matters: Turing Equivalence in Automated Systems Administration.

10. Bigger mindshare

Though not a technical consideration, this is probably the most important. When you say ‘configuration management’ to most people (at least people who know what you’re talking about), the usual answer is ‘Puppet’. Puppet owns this space. I know there is a large and helpful community I can call on for help, and even books published on Puppet. Puppet is so widely adopted that virtually every problem you could encounter has already been found and solved by someone.

Conclusion

Currently ‘Chef vs. Puppet’ is a rather unfair comparison. Many of the perceived disadvantages of Chef that I’ve mentioned above are largely due to the fact that Chef is very new. Technically, Puppet and Chef have similar capabilities, but Puppet has first mover advantage and has colonised most corners of the configuration management world. One day Chef may catch up, but my recommendation today is to go with Puppet.

Culture and incentives

Culture is an important reason as to why people gravitate to one tool or another. Chef will draw in Ruby developers because it’s not declarative, and because it’s easy.

My experience is that most developers don’t do declarative systems. Everyday languages are imperative, and when you’re a developer looking to get something deployed quickly, you’re most likely to pick the tool that suits your world view.

Systems Administrators tend to use more declarative tools (make, etc.)

Developers and Systems Administrators also have a divergent set of incentives. Developers are generally rewarded for delivering systems quickly, and SA’s are rewarded for stability. IMHO, Chef is a tool to roll out something quickly, and Puppet is the one to manage the full lifecycle. That’s why I think Chef makes a good fit for cloud deployment because Vm instances have a short lifespan.

I think it’s still anybody’s game. The opportunity for Chef is that the developer community could build out an ecosystem very quickly.

Re: Culture and incentives

That’s a great point - I hadn’t thought of make as a declarative language, but it kind of is and isn’t!

The only thing I would say is that if Chef is useful primarily for quick’n’dirty rollouts, it’s not clear to me why you wouldn’t just use a shell script for this. (I’m sure a lot of people do.)

Declarative vs. Imperative

It certainly may be true that imperative systems are more easily understood, but I’m pretty sure the majority of declarative tools that spring immediately to mind (Make, XSLT, erlang) are all developer rather than sysadmin tools.

Culture & Incentives != Right Tool for the Job

I’m a sysadmin now, but my initial background was in software development. When starting out with Puppet, which we migrated to from CFEngine, I had to learn to stop doing what was “comfortable” in my imperatively-molded mind. One of the big problems we found with CFEngine is that it was too easy to have people manage the same resource with multiple configuration directives, which caused more than its fair share of problems. With Puppet, we were inherently protected from that pitfall. I’ve come to believe that while having a declarative DSL implemented by my configuration management provider can make things tricky at times, the benefits far outweigh the drawbacks, for many of the reasons stated in the article above.

Also, I’m not sure that you can just lump sysadmins into dealing with mostly declarative stuff. I would argue that the majority of the stuff I deal with isn’t. With respect to “delivering quickly” versus “stability”, I have to argue that “done right” is almost never equivalent to “done right away” regardless of whether you’re a developer or a sysadmin, and that should have little consideration when deploying a configuration management engine. For my money, I’d rather do it the right way from the start to avoid deploying the wrong tool and wasting time & resources re-deploying with the right one and having everybody learn another DSL that operates completely differently. Perhaps that’s why developers don’t double as sysadmins - as you state, products rolled out with haste are far less likely to offer the stability required than their well-thought-out counterparts.

Finally, I’d argue that you could use Puppet to roll out new Puppet-capable VMs, which doesn’t require any lengthy lifecycle. We do it all the time. Look, I’m not saying Chef sucks, I’m just saying that Puppet is a better tool for the job, having evaluated and tested both. I don’t think that Chef will really gain much of a foothold, or steal any market share from Puppet - people aren’t going to rip out their current installations for a variant of the same thing that offers little innovation and improvement over the original. If you want to leap ahead of your competition, you have to do something differently, and removing the DSL in favor of a raw programming language just doesn’t cut it.

Quick lifespan is still a lifecycle

What a developer hands off to ops as a fast and quick, often becomes legacy.
VM instances may OR may not have a short lifespan.
I’ve seen many VM’s live a long time….that were originally ‘stop gap’ intentions.

Puppet has put in AWS and VMware cloud support

So that eases out cloud deployments and makes them way quicker now.
Changes the game drastically I’d say :)

It seems to me that both

It seems to me that both system have quite a bit of support out there and it really comes down to what you as the sysadmin/developer prefer.

I would also agree with ripienaar’s tweet about disagreeing with point 6. Configuration management systems are not really intended for deploying software but for making sure that systems conform to a certain policy ie. webserver policy etc.

Re: It seems to me that both

Thanks for the comment - I agree that both systems have some support, but I think if you were to quantify things you’d find Puppet probably has 10 or 100 times the users that Chef does.

I’m not sure what it means to say that config management systems aren’t for deploying software. Developers usually have an existing solution (eg Capistrano) for the actual deployment. The config management side of it is usually about providing dependencies such as users, gems, web server software, etc. Or did you mean that you think Chef is primarily a deployment tool?

I'm a SA and have worked

I’m a SA and have worked closely with developers for years. It never ceased to amaze me how differently we think. It does boil down to priorities, culture, and incentives as Julian mentioned. I have not used Chef but I saw quite the stir the last time I mentioned puppet Puppet Works Hard To Make Sure Nodes Are In Compliance.

I have used puppet both as a deployment tool and a configuration management tool. It really can do both just fine as a deployment is essentially a configuration change. But I have found it easier to use a tool like fabric when I need to perform “actions” on a group of machines, especially when those actions are many and very possibly one time. I have found it a bit daunting if you put too much into your configuration management tool as over time it becomes a lot to sift through, and when its time to remove a configuration you have to leave that part of the configuration there (the part that removes whatever it was).

Maybe I haven’t looked around enough but I really want to see a puppet reporting tool. I know bcfg2 has a decent one. I want to be able to know the current stats of my nodes, who is in compliance, who isn’t, when I last spoke with what node, last time nodex changed and what changed.

http://theforeman.org

http://theforeman.org provides reporting among other things (inventory, OS unattended installations etc)

Your background on the two?

As with many comparisons between software packages, it’s very hard to be objective - most people do research on multiple solutions, but only have real-world experience with one.

What’s your experience in configuration management - have you used Chef at all?

Re: Your background on the two?

It is hard to be objective - probably impossible. I’m sure I haven’t been.

My background is that I’ve used Puppet for commercial sysadmin work for several years (basically since it came out), and it currently manages many infrastructures for many of my clients (I’m a freelancer). The biggest deployment I’ve worked on is probably 25-30 servers, and a comparable number of desktops. Maybe 6,000 lines of manifest code (not counting templates).

When Chef was first announced, I set aside time to build a Chef server and try it out, with a view to adopting it if it was superior to Puppet. I found it quite hard going (admittedly that was early days for Chef), and I didn’t find sufficient advantages for Chef to migrate any of my clients to it. If a client asked for Chef specifically, I’d be quite happy to use it, but so far no-one has.

So based on what I know, I use Puppet and that’s what I recommend to others. I’m very interested in hearing from anyone who knows different.

Do your homework

Readers, do you homework too and stop reading articles with the title ‘versus’, the hallmark of propaganda. If you must read on, some specific points, with disclosure that I’m a Chef early adopter with previous Puppet exposure.

#1, #2, #5, #7, #10: puppet is more mature than Chef

All software starts with a small install base, fewer adherents, etc. That doesn’t make it more suitable for your specific environment or taste in software development (configuration management is development too). The answer here is to try both systems yourself and compare them - something the author of this article seems to not have done yet. It’s not just about the code, it’s about the software used to deploy it, the way it authenticates, etc. These things should also influence your decision.

#9: Dependency management

Chef has no support for specifying dependencies (ordering resources). Chef is like a shell script: things are done in the order they’re written, and that’s all.”

Chef’s default behavior is to process resources in the order you write them. It has other dependency features just like Puppet does - see below.

A resource in Puppet can ‘listen’ for changes to things it depends on: if the Apache config changes, that can automatically trigger an Apache restart. Conversely, resources can ‘notify’ other resources that may be interested in them.”

This has been possible in Chef for a long time. See this real world example: http://gist.github.com/276246

http://wiki.opscode.com/display/chef/Resources - See the ‘notifies’ attribute in the Meta section.

#3 Dedicated configuration language

Ruby is a good general-purpose programming language, but it is not designed for configuration management - and learning Ruby is a lot harder than learning Puppet’s language.”

Sysadmins who can code can learn Ruby quickly, and there are plenty of resources on how to write Ruby. While most of the time you can stick to the Chef style of Ruby, you have access to the power of a mature programming language for free. If you think this language is easier, show why that would be the case for someone who already knows at least one programming language.

I see nothing inherent in Puppet’s language that makes it better suited to configuration management. If you think there is, show some examples.

#6: Language/framework neutral

Straight up bullshit here. There is nothing in Chef specific to Ruby on Rails. All chef deployments I know of (including our own) are used for deploying entire stacks of software totally unrelated to Ruby or Rails, just like Puppet.

Conclusion: In the next installment, show more code examples and tell us why Chef didn’t work for you where Puppet did. Try both software packages the day before you write the article, not 6 months before. Assume your readers write code and already know that adopting less mature software is more risky.

Agree

I’d agree with almost everything above, this strikes me as mostly self promoting b/s written with the express intend on driving traffic to a blog. Especially given the spammy nature of its promotion.

As an aside, and I wouldn’t want to distract from the fantasy here with actual facts, but Puppet is getting native Ruby base DSL some time soon and so will please both sides of that particular fence.

Re: Do your homework

Readers, do you homework too and stop reading articles with the title ‘versus’, the hallmark of propaganda.

Is this one of those ‘Mine is advocacy, yours is propaganda’ things?

I was just about to post a

I was just about to post a response to this mindless, and contentless article, was glad to see you saved me the trouble.

Oh dear god

This is like vi vs emacs all over again,

More useful comparison

Here’s a better, more balanced article comparing real world usage of Chef and Puppet.

http://bhuga.net/2009/09/puppet-vs-chef

Re: More useful comparison

Here’s a better, more balanced article

The author also chose Puppet over Chef.

(I agree that it’s a better and more balanced article though.)

Chef has more contributors than Puppet!

Ohloh is unreliable. Often

Ohloh is unreliable. Often projects will go unscanned for months.

Try using something like http://github.com/mpdehaan/lookatgit

Ohloh broken

In fact I can confirm that Puppet’s enlistment failed again a month or so ago and hasn’t been updated since. I’ve not bothered to follow it up as it’s a regular occurrence.

Love the passion

Hi John! Thanks for being passionate about my favorite space - configuration management. You do great work, and I know your intent wasn’t necessarily to sow discord - but I wanted to take a moment to comment on a few of your points that I think are either wrong or missing some important context.

1) Large installed base

Chef has somewhere in the neighborhood of ~1500 working installations. It’s true that our early adopters are primarily large web players like Wikia, Fotopedia, and 37signals. We also have a growing number of people integrating Chef directly into their service offering - it’s not just Engine Yard, it’s RightScale and others.

2) Large developer base

According to Ohloh, 39 developers have contributed to Puppet in the last 12 months, and 71 over the projects entire history.

Chef has been open source for a year. We just had our 100th CLA (contributor license agreement, meaning they can contribute code). Over the course of the year, 52 different people have contributed to Chef, including significant functionality (for the record, 5 of them work for Opscode.) We’re incredibly proud of the community of developers who have joined the project in the last year, and the huge amount of quality code they produce.

3) Dedicated Configuration Language

To each their own, man. :) My preference for writing configuration management in a 3GL was born out of frustration with doing the higher order systems integration tasks. By definition, internal DSLs aren’t meant to do that - when they start being broadly applicable, they loose the benefits they gained from domain specificity. For me, the benefit of being able to leverage the full power of a 3GL dramatically outweigh the learning curve, and I think a side-by-side comparison of the two languages shows just how close you can get to never having to leave the comfort of your DSL most of the time.

4) Robust Architecture

Chef is built to scale horizontally like a web application. It’s a service oriented architecture, built around REST and HTTP. Like cfengine, it pushes work to the edges, rather then centralizing it. There are large (multi-thousand node) chef deployments, and larger ones coming. Chef scales just fine.

5) Documentation

It’s true, we’ve been focused pretty intently on refining Chef in tandem with our earlier adopters, and that focus has had an impact on the clarity of our documentation. Rest assured, we’re working on it.

6) Language/Framework Neutral

I’m not sure where this comes from, other than we’ve had great adoption in the Ruby community. People deploy and manage every imaginable software stack with Chef - Java, Perl, Ruby, PHP - it’s all being managed with Chef.

7) Multi-Platform

It’s true that, at release a year ago, Chef didn’t support many platforms. Since then, we’ve been growing that support steadily - all the platforms you list run Chef just fine, with the exception of AIX. We have native packages for Red Hat (community maintained by the always awesome Matthew Kent!) and Ubuntu that ship regularly at every release. As for the Chef Server only running on Ubuntu - that’s just not true.

8) Doesn’t re-invent the wheel

Again, to each their own. I think Chef’s deterministic ordering, ease of integration, wider range of actions, directly re-usable cookbooks, and lots of other things make it quite innovative. I’m pleased to explain it to you over beer, on my dime. :)

9) Dependency Management

While I understand how you can think this would be true, it isn’t. Chef does have dependency management, and a more robust notification system then Puppet. Each resource is declarative and idempotent. Within a recipe, resources are executed in the order they are written - meaning the way you write it is the way it runs. This is frequently the way puppet manifests are written as well. The difference being, there is no need to declare resource-level dependency relationships.

With Chef, you focus on recipe-level dependencies. “Apache should be working before I install Tomcat”. You can ensure that another recipe has been applied at any point, giving you great flexibility, along with a high degree of encapsulation.

One added benefit of the way Chef works is that the system behaves the exact same way, every time, given the same set of inputs. This greatly eases debugging of ordering issues, and results in a system that is, in my opinion, significantly easier to reason about at scale (thousands of resources under management).

10. Big Mindshare

There is a bit of survivor bias happening here. I meet people every day who are starting with, or switching to, Chef. You don’t, because, well - you don’t use Chef.

* Conclusion

Thanks for taking the time to write about Puppet and Chef - I know your heart is in the right place. Next time, come talk to us - we’re pretty accessible guys, and I would be happy to provide feedback and education about how Chef works. I won’t even try and convince you to switch. :)

Best regards,
 Adam

License

Adam,

wicked comment. You touched a bit on it, but Apache 2 is a much much better license than GPL for a tool like this, you guys did well to choose that.

Puppet has it on the roadmap but I think its some way off imho

Re: Love the passion

As for the Chef Server only running on Ubuntu - that’s just not true.

Hey Adam,

Sorry to have got this wrong. I’m pretty sure that I found this statement on the Chef wiki itself, but try as I might, I can’t find that now. I’m happy to amend the article - does the Chef server run on all Chef’s supported platforms? If not, is there a list I can look at?

For the server, the main

For the server, the main things are having a sufficient version of Ruby for Merb (1.8.6-1.8.7, 1.9 support is in progress), and CouchDB (0.9.1+ is recommended). Once those requirements are met, then chef-server installation via RubyGems works in my testing:

debian, ubuntu, centos, fedora, opensuse, opensolaris, freebsd, openbsd, macosx, mandriva, archlinux, gentoo are all functional as servers.

I don’t have access to an AIX system to test, though.

Platform specific support for Chef in general is up to providers for the resources, mainly user, service and package.

Not picking Joshua but Ruby

Not picking Joshua but Ruby 1.8.6-1.9 and Couch does mean that Chef servers run on a smaller sub-set of platforms (and versions of platforms) than Puppet masters can. Just to be clear. :)

Puppet works down to Ruby 1.8.1 and shortly up to 1.9 as well.

Puppet also doesn’t rely on any associated gems that need to be installed. It is my understanding that the only natively packaged hosts currently are Ubuntu and Matthew Kent’s Red Hat RPMs? The others require that you install Gems?

Sorry - should have been

Sorry - should have been clear - Debian/Ubuntu.

I tend to agree with Adam's

I tend to agree with Adam’s responses to John here.

I think the analysis of the pro/cons is a bit weak and unsupported by factual examples. I think some of John’s points (5 for example) are probably true but should be better supported and reasoned.

It’s well known - hi Adam! - that I disagree philosophically and operationally with Chef’s approach to 3) and 9). Of course, my disagreement with 3) becoming somewhat moot given Puppet’s Ruby DSL coming in the next major feature release. :)

The ordering misconception.

Adam,

There is a misstatement in your assessment of Puppet’s dependency handling. You express Chef’s ordering as deterministic and imply that Puppet is in someway non-deterministic. This is not the first time you have implied this publicly, so I thought I should bring some clarity to your misstatement. The actual differentiation is procedural ordering versus a dependency graph. Puppet provides a graphing model for ordering versus a procedural model. Sure, you get procedural ordering for free with Ruby, it seems easier, and I am aware that this was a design decision for you guys. We also know that you were frustrated by “having” to express dependencies in Puppet in order to ensure consistent ordering. Properly expressed dependencies in Puppet provide ordering where you care to have it. Procedural ordering is implicit even if you don’t care. This is a BIG difference, perhaps the fundamental difference between Puppet and Chef and one that was designed into Puppet because of experiences we had trying to cope with a large code base of procedurally order scripts to manage an enterprise infrastructure. Yeah we were using make, yeah that was crazy, crazy but informative.

Your omission is related to your design decision to avoid dependency graphing, which you yourself have admitted has some major downsides, namely the inability to provide a reasonable dry-run mode, http://bit.ly/4Gcz7G. Frankly, I don’t know how you develop with out a dry-run mode, but hey I am a sysadmin not a developer.

Without a graph of resource dependencies, we would have no way of separating concerns. Consider the use case of implementing security standards. Ideally, you would want any given configuration run to bring your system into complete compliance. That sounds great but would you really want security policies not to be implemented because some earlier procedure was unable to succeed, say because it was pulling in data from a source that was not available.

So here is the difference in a nutshell. Puppet generates a catalog of dependent resources. This catalog is shipped to the clients and acted on by the Resource Abstraction Layer (RAL). On the other hand Chef, ships the required Ruby code for any node’s configuration and orders the execution of that code procedurally. These are the core differences. The DSL issues become moot if you consider Shadow Puppet or the Ruby DSL that we are developing as part of Puppet’s next release. The real difference, and IMHO Puppet’s advantage is our resource model and it’s dependency graphs versus a monolithic procedural chunk of Ruby code delivered to every client.

Here are some derived advantages of our model and a little love for the much maligned declarative external DSL:

1) Graphing base branch independence.

Parts of a catalog can be implemented more often than others. That is to say, we can tag certain resources to be checked and reconfigured more often. Additionally, parts of a configuration can be meaningfully checked but not acted on (See Adam’s discussion of noop http://bit.ly/4Gcz7G). Our customers/community love this and without a graph I don’t see how it is possible.

2) Cross host dependencies.

Our data model passes dependencies into our catalog caching system, so cross host dependencies can be resolved as well. This isn’t currently available but the framework exists and we intend to take advantage of it.

3) Failures are contained.

Critical parts of a configuration run are not excluded because of non-dependent failures.

4) Low barrier to entry for non-rubyist.

Non-rubyist can take advantage of the specification language out of the gate and Ruby developers can take advantage of the current Puppet plugin API and the future Ruby DSL, so everyone gets to use their favorite hammer.

5) Don’t like our DSL, don’t like Ruby?

Because we are only generating a catalog from the configuration language it should be fairly straight forward for anyone to generate a catalog using whatever language they choose and the RAL would be able to act on it. Come on Python people you know you want to generate catalogs with Python.

6) I can’t run Ruby on my switch!

Because we are using a data model for resources, devices that can’t/don’t have access to Ruby could still use the catalog as a basis for configuring themselves. Routers, switches, firewalls, could all be configured using the same specification language independent of how the specification is implemented, but with the resource model intact.

Finally, I think that you were a little hard on John about his comments on Chef being Rails focused. Certainly he misspoke, but the truth is that Chef development has been focused on web-application rollout in fairly homogeneous environments. Sure you can use Chef to manage the initial deployment of a web application, but in environments where you may have lots of teams utilizing compute resources for various application architectures, Puppet’s resource model shines. Security administrators can develop their Puppet manifests and not need to worry that security policies are not going to be applied because the DBA teams manifests failed. Operations teams can run Puppet in noop mode persistently and be notified if their configuration is out of compliance. Developers can make sure that the infrastructure they need for successful application deployment is available without having to worry that the security policy failed to be applied. Everyone gets to be friendlier with one and other and perhaps even get to the pub earlier on occasion.

Cheers,
 Teyo

Teyo, Any omission on my part

Teyo,

Any omission on my part isn’t intentional - I’ve spent a good portion of the last few years being a Puppet advocate, and I certainly don’t feel any ill will towards you, Luke, or the project. I think I’ve been pretty clear in the past about exactly what I mean by Puppet being non-deterministic, but let me make it clear here again, and clarify some things about Chef’s implementation that I think you may misunderstand.

As you describe, Puppet builds a directed graph (http://en.wikipedia.org/wiki/Directed_graph), where the vertices are resources (things to be managed) and the edges represent the explicit dependencies between those resources. When it comes time to execute that directed graph, Puppet does a topological sort (http://en.wikipedia.org/wiki/Topological_sort), which results in a path through the graph where each resource appears only once, and dependent resources come earlier in the resulting list.

One property of a topologically sorted directed graph is that, unless each pair of successive vertices in the sorted set is connected to one another by an edge, there are many possible solutions to the sort. In plain language, the final order of execution of resources in a given puppet catalog will vary unless every resource has a single explicit dependency linking it to another resource (and so on, back to a single starting resource).

The impact of this property on Puppet is that, in almost all cases, you do not have a deterministic run order for the catalog. You have a deterministic run order for *portions* of the catalog, but not the entire working set. My experience with this property at scale was that, as the number of resources under management increased (we had systems managed with puppet that had more than 1500 resources being managed,) order-related bugs in the build were harder to reproduce (and therefore to debug). Recreating the context was difficult, since as the number of resources in the graph increase, so too does the number of possibly valid sorts, any one of which may (or may not) contain the actual bug in the final configuration. Personally, I was happy to give up base branch independence for determinism. Plenty of folks disagree with me, and that’s okay - I still like them.

Saying Chef is ‘procedural’ is a fun rhetorical nit, but it belies the reality that Puppet, Chef, Cfengine, Bcfg2 and AutomateIT all take a ‘declarative’ approach to configuration management. You declare the final state you want a resource to be in, and the systems themselves determine what specific commands need to be run (or not run, they are all also Idempotent) on your behalf. Procedural, Declarative, and Idempotent are not orthogonal properties. But you already know that. :)

As for the list of advantages you posted, the reality is that none of those features (other than ‘I like the Puppet DSL’) actually stem from the decision to use a directed graph, or are uniquely implementable because of that choice. Want contained failures in Chef? Just have more than one run-list (ie: execute the policy in pieces). Low barrier to entry? Using Chef requires very little Ruby knowledge. Can’t run Ruby on switches? Well, switches can’t parse puppet catalog’s either - we’re both going to have to build some intermediary there. Cross host dependencies? You’re entering into distributed systems and locking territory, and Puppet’s directed graph doesn’t magically give you a PAXOS (http://en.wikipedia.org/wiki/Paxos_algorithm) implementation - we’re all going to have to cross that bridge some day.

To address your comments about a no-op mode in Chef, that thread continues on from the message you posted. The gist of it is that, when you take a dry-run on an unconfigured system, the results (regardless of it being puppet, chef, or any other tool) are unreliable. All you can do is evaluate each resource in isolation, and assume that each dependent action was also successful. In a world of virtual machines with instant roll-back, and two minute cloud computing boot times, my personal experience has been that it’s cheaper for me to just try it (and perhaps use integration testing tools like cucumber to verify it) than it is to read the output of a dry run. Later on, several members of the Chef community pointed out some excellent use cases for a dry run mode with Chef - the primary one being they wanted to see the incremental changes that would be made by smaller policy choices. They’re right, that’s a great feature, and a no-op mode is on the road map. Nothing about Chef’s implementation make a no-op mode impossible - just as nothing about Puppet’s implementation makes it more suited to having one.

As the Perl folks like to say, there is more than one way to do it. Each tool has different philosophies about which features they think are most important, and why, and has different benefits (and flaws) in different scenarios. Lets both get past the “you guys can’t” and “mines better than yours” and get back to the business of building the greatest generation of systems management tools that have ever existed… because that’s all anyone cares about anyway.

Best regards,
 Adam

Multi-platform?

@Adam, with reference to #7, Chef seems to have a lot of issues when it’s installed on Fedora (14/15). I have been trying to get it up and running on both these Fedora distros, and have run across numerous issues, including not starting up at all. The wiki is extensive, but only helpful when everything works as expected. Sadly, they don’t.

The mailing list has not been of help. It’s also telling that a search for “Fedora” on the opscode mailing list turned up just my own questions.

Have you actually even used Chef?

Some of these points (6, 7, and 9) are just completely false.. Which makes me wonder if you’ve even used Chef? I’m no fanboy.. Chef has its ups and fowns.. But just lets be objective here..

As for point 3, its actually a benefit. There is a high learning curve to figure out how to properly use Puppet’s DSL. Puppet is also coded in Ruby, but you have to learn their obscure DSL on top of that (which is non-trivial). Chef has a curve as well, but once you get the basics, you can use the expressiveness of the ruby language to add whatever functionality you want

Let's do a bit more research next time.

> If you’re already using Puppet, Chef doesn’t really offer anything new which would make it worth switching.

That’s not true. I think the problem is that there aren’t any real-world people blogging about innovative uses of chef yet (but they will). Puppet’s custom DSL will *always* be limited compared to a DSL embedded in a real language. Once you try to do something nobody ever thought of, you will “fall off the cliff” of complexity and find it’s easier to implement outside than inside. Sure, you can write your own objects deep inside the system, but that’s not the same as being able to say call functions to compute attributes, or having complex if-then logic and complex subroutines.

In may ways, I find that Chef is similar to Rails. First, they both share the “everything in it’s place” big directory structure. Second, they can be extended in ways nobody has thought about. Third, they take time to learn, so they will ramp up slowly. When Rails started, the documentation was terrible. But once some bigwigs started blogging about real-world problems they solved elegantly, it was clear that Rails was on to something. The same will happen with Chef.

4) you are calling Chef architecture “not robust” without any evidence. If you make the claim, you have to supply the evidence. FUD.
6) Chef deploy is similar to Capistrano, and that’s used by many non-ruby folks. Chef just does a git checkout and runs a UNIX command. How is that Ruby specific? FUD.
7) The server is just Ruby, so there isn’t much work to “porting” it. The clients require a few tweaks for different package systems. Plus, you can use Chef-solo without the server. Chef is already multiplaform, so the title is FUD.
8) Seriously, you think Chef re-invented the wheel, but Puppet didn’t? Triple FUD.
9) Dependencies work fine in Chef. FUD.

John: your article contains so many proven false statements that you should put a big disclaimer at the top. Let’s stop spreading the FUD so we can start a real dialog.

Adam: lean on your users to start brag^H^H blogging more. Searching cookbooks isn’t the same as a blog post about why someone did it that way.

MCollective is not related or exclusive to Puppet

MCollective works just fine with both Puppet and Chef and anything else that can make a text file with list of configuration management object. Further for facts it works with Ohai as well as Facter - and in fact with a simple yaml file if thats your thing.

MCollective is also not designed as a Puppet plugin and has basically nothing to do with it, it just happens to compliment either Puppet or Chef well.

http://code.google.com/p/mcollective/wiki/UsingWithChef
http://code.google.com/p/mcollective/wiki/UsingWithPuppet

The chef guys have been more than helpful when I needed the integration, kudos to them. Puppet I could do myself being a user.

Honestly, 2 minutes of homework is all it takes.

Is this typical bitfieldconsulting analysis?

One point that, IMO, is not emphasized enough by IT analysts is that when you ‘invest’ in learning a new ‘language’ or skillset, you want that investment to payoff as often as possible. Do bitfieldconsulting really advise their clients that there can be a long term payoff, for their teams, from time spent learning Puppet’s DSL?
Of course there is a ‘glorious-isolation’ world view, and some IT people do think that having the most narrow or obsure skill base makes them more valuable. IMO this misses the fact that your ‘value’ can only increase if _demand_ for your skills exceeds the supply. It is a common trap to twist the logic and think ‘If I tool up on things fewer people know then my time will be more valuable’ - totally ignoring that several people have to _simultaneously demand yours, and no-one else’s time before you even get to think about premium’s.
What to make of the user base size comparison, given Chef is one year old? No insight from bitfieldconsulting. What to make of Puppet introducing ‘Puppet’s Ruby DSL’? (Actually what does that mean, I thoight Puppet is a Ruby DSL). Sounds like even Puppet’s parents eventually learned some lesson about somthing and are trying to switch. Bitfieldconsulting could have given some insight into what this reveals about insights, into the domain knowledge, driving both projects - anything?
What to make of the licenses? What to make of the issue of non-idempotent deployments? A non-issue? At scale? Again what does this allow someone to infer about ‘Why Puppet wins’.

From what I’ve gathered from various blogs, Puppet might be suitable when:
- You are never going to deploy at scale (when you will hit the issue of your machines being in some random state - good luck tracking that down), or it doesn’t matter if things get tangled you are able to just keep retrying until things are the way you want them to be. Together, these characteristics suggest very small low-IT-skill base shops (usually the owner doubling as the IT), of which there are many, so is a viable market (how many laywers, accounts, doctors, dentists want to learn Ruby? Does Puppet really trump a Redmond firm’s offering in this segment?)
- You will never have need for a more generally applicable language like Ruby (see above user list). This could be due to genuine time constraints (understandable if you’re the ‘IT-dentist’ in a four partner practice) or you’re one of IT’s ‘glorious-isolationists’ (puzzling).

Most puzzling is why a consulting firm would publish this analysis under their company’s blog?
After reading this post I wouldn’t touch bitfieldconsulting with a barge pole. So the post _has_ given me important and valuable information (steer clear of bitfieldconsulting, and reconsider technologies they advocate), but that information harms the firm. Puzzling indeed.

"From what I've gathered from

From what I’ve gathered from various blogs, Puppet might be suitable when”

You do though in your own analysis of the situation fall into the same trap, you don’t know the tool you are bashing and base it on something you’ve read and not experienced.

Fair points, just saying, it has as much merit as the original post.

"You do though in your own

You do though in your own analysis of the situation fall into the same trap, you don’t know the tool you are bashing and base it on something you’ve read and not experienced.”

Hmmmm, now it is a “trap” to base your understanding on several things you’ve read and not experienced… “I don’t trust them City folk and all their book-learning” ;)
That was just to make a point: I am a old farm boy :)

Note I do suggest there are reasons you might choose Puppet. True, I consider them to be weak.

You are correct about my opinion being informed from other’s experiences (that reading skill I picked up turned out to be useful).
I clearly state I’ve formed my opinion on others accounts - not unreasonable.
My recollection is those (several) accounts were not from Chef/Opscode insiders.
We don’t all have time to switch our infrastructure over to ‘X’ give it a full workout and then switch to ‘Y’. Not because it can’t be done, but because it is not practical. Others have posted their experiences - it seems fair to be informed by them.
Yes I am aware people might have ulterior motives. However, I haven’t seen _any_ blogs showing the “Puppet can get stuck when it’ll hurt you (large/complex deployments)” is not so, pointing out how other’s claims are due to operator error (i.e. not Puppet error). I also haven’t yet seen anyone who asserts “it-just-ain’t-so” actually point to some supporting accounts.
I don’t buy ‘believe me’, or ‘would firm X using it if it wasn’t better than sliced bread’. If the later were sufficient reason, we’d all be using “Windows” _and_ Linux wouldn’t exist.

Rather than just _claim_ “this is not so”, could you please point to at least a couple of blog posts (independent of Puppet/Puppet Labs’ insiders) establishing Puppet does not get ‘stuck’? I think this is the central criticism.

I do still track Puppet so can’t be accused of having a closed mind.
I am very skeptical about IT people wanting to protect the value of their ‘investment’ in their skill set (a sunk-cost), so several independent accounts would be needed to be convincing.

I agree with the critique of

I agree with the critique of the original post. In the rest of your comment you descend, as guilty as the original poster, into unsupported and poorly reasoned FUD.

As I just re-marked

As I just re-marked above.
Please point me to accounts (independent of Puppet/Puppet Labs insiders) showing that:
- Puppet does not get ‘stuck’ when it will hurt most - large complex deployments
- Prior user accounts are due to user error not Puppet’s behavior.

Re: As I just re-marked

Mark,

Large complex deployments are exactly where Puppet does score - and I’ve got several case studies from clients which I plan to write up for this blog which demonstrate just that.

And I’m not a Puppet insider (though I do have the T-shirt).

10 ways of saying Puppet has the inertia advange

That’s all you got? I mean, it’s something I guess, but still.

Fantastic commentary

I don’t think the article was as unfair as some people are making out, and certainly the criticism that it’s link bait with “versus” in the title is unfounded, because that’s exactly what I googled for and it’s really the best way to title a comparison for searchability. More importantly, you brought Teyo and Adam to the party, and their conversation was perhaps the most enlightening aspect to someone like me who’s just beginning to explore configuration management tools. Thanks for the great commentary guys!

Re: Fantastic commentary

Thanks - a good discussion in the comments was exactly what I was aiming for, and I think we definitely achieved that. Often the best way to get input is not to ask for opinions, but simply to present your own and wait for everyone to disagree with you ;)

Weak

I don’t remember the last time I read an article/blog post pretending to present an objective comparison between tools/products/technologies which felt as weak as this one. I see no hard facts, no ‘lessons learned’, no ‘here’s what failed for me in Chef and worked in Puppet’ — only ‘I think Puppet is better because I couldn’t install Chef some time ago’.

I shouldn’t be surprised though, since this blog is used as a google link bait by appropriating topic titles blogged by other authors. If you see this link in google: http://bitfieldconsulting.com/chef-tutorial-part-2-cookbooks-and-roles you would think John Arundel blogged about it. It’s only when you click that you see that it’s actually just a link to my blog post on that topic.

I am no fan boy of either Puppet or Chef. I’ve used both, and I think both have merits. As with any technology, the choice strongly depends on a lot of other factors and is never as clear cut as it’s made out to be here. I bet the author will blog next about ‘MongoDB vs. CouchDB: 10 reasons why one of them wins’.

Weak

10 points, all the same item repeated “more people use puppet therefore it is the best tool for your job”

This article was in no way helpful.

Horrible Docs

I haven’t looked at Chef yet but Puppet was painfully poorly documented. It was so difficult to understand how to even start I just gave up and wrote my own install scripts using git and gem repositories and drive images. It’s pretty sad when a total newbie can write their own scripts faster and more easily than they can understand a product’s documentation.

Puppet tutorial (Re: Horrible Docs)

I tend to agree. However, I think the Chef docs are equally lacking.

Did you try my Puppet tutorial series?

Puppet Tutorial

Re:

In 1993 cfengine was one of the first open source configuration management systems for Unix, and the first to perform self-healing, long before IBM’s autonomic computing initiative drew attention. Cfengine is now used on hundred of thousands of computers all over the world. Besides, there is a video on the promise of system configuration which helped me to weigh the pros and cons. In the late 1990’s Mark Burgess came to realize that no one was really conducting research into large scale computer behaviour and he began to work on all aspects of system administration. Recently he introduced a model now known as “Promise Theory” to describe how autonomous systems collaborate — as there was no good model to describe how cfengine worked. In the light of this research cfengine has now been completely rewritten to take advantage of the results of this model — resulting in big simplifications as well as much greater power. In this talk, Mark will describe the case for promises and explain why 50 years of deontic logic have been no help whatsoever in solving system management problems.
As for me, I would also use Puppet. I am still considering pros and cons, and I think the best tip for me as a beginner is that whatever you’re trying to manage with Puppet, you’re likely to find that someone else has done the same and can help you.

I agree with this list, with

I agree with this list, with the exception of #3, which sounds like exactly the opposite of all the other reasons!

Puppet is better because it has more developers, more organizations, more use cases, more documentation, more platforms, and no wheel reinvention! … uh, except for the configuration file, which uses its own special syntax, with far fewer developers, fewer organizations, fewer use cases, less documentation, its own special parser.

What sysadmin doesn’t know at least a little Ruby already? What programmer can’t figure it out quickly? If I get stuck, I *like* having a gazillion resources to help me (Ruby syntax, XML, …), not just a few (Puppet syntax). That’s a feature.

That’s why we like XML for config files. Not because XML is a good fit for config files (because you’re right, it’s not) but because we already know how to write an XML document and do character escaping and everything. Heck, Mandarin might be perfect for configuration but all the characters would be new to me, and ASCII might not be great but I know it already so I’m not thinking about it at the level of the characters any more.

Does anybody like having to look up how to do escaping or quoting in config format 7,233? I’m also not a fan of having tools that never work quite right because the syntax is not quite like anything else they know how to use (and it’ll never be popular enough to get broad tool support).

#$%SB

(That’s how you say “OK, I’ll get off my soapbox now” in my own language. I would have said </soapbox> in XML but everybody knows XML is exceptionally poor for getting off soapboxes. Fortunately this comment box lets me use HTML escapes so I could type that. :-)

except for the configuration

except for the configuration file, which uses its own special syntax

The argument that ‘Chef is just Ruby’ carries less weight once you realise that Chef’s language is a Puppet-like DSL implemented in Ruby, which you also have to learn. Knowing Ruby doesn’t mean you know how to do anything in Chef. Take this example:

include_recipe 'gems'
include_recipe 'applications'

template "/data/someservice.conf" do
  owner node[:user]
  mode 0644
  source "someservice.conf.erb" 
  variables({
    :applications => node[:apps]
  })
end

There is not a single bit of Ruby in all of that (except ‘do..end’). That is all Chef syntax which you just have to learn, as with Puppet - in fact it’s very similar to Puppet’s syntax, because it’s doing pretty much the same job.

Of course if you need to do some complicated logic, you can use Ruby for that. So you can in Puppet, using an inline template or the Ruby-embedded version of Puppet’s DSL. So “Chef is Ruby”, while true, is misleading. You could also say “Rake is Ruby”, but it doesn’t mean that you know Rake if you know Ruby.

What sysadmin doesn’t know at least a little Ruby already?

Actually, quite a few of them. Many sysadmins don’t program at all, beyond a little shell scripting, and they don’t see that as their job. Out of the sysadmins I know that do code, probably the majority prefer Python.

That’s why we like XML for config files. Not because XML is a good fit for config files (because you’re right, it’s not)

I’m not sure I really understand your argument here. Are you saying that it’s better to use something which is a bad fit for the job, because it’s familiar and thus you can start using it more quickly? Or because you don’t have to expend any effort learning it?

I wouldn’t give these arguments much house room in the context of sysadmin. New and better tools are always coming along, and I see it as part of my job to put some brainpower into learning them and applying them, if they prove to be the best tool for the job.

Anyway, if you are saying that we should use Chef rather than Puppet because Chef is Ruby and therefore we already know it, see my point above for why this isn’t the case.

Chef is most definitely

Chef is most definitely easier for developers with an inclination for sysadmin. I tried both and Puppet just didn’t stick.

This is how your Chef example would look like in pure Ruby:

include_recipe 'gems'
include_recipe 'applications'

template "/data/someservice.conf" do
  :owner      => node[:user],
  :mode       => 0644,
  :source     => "someservice.conf.erb",
  :variables  => { :applications => node[:apps] }
end

Easy to understand why Ruby developers find Chef’s syntax a no brainer.

It’s not the syntax which

It’s not the syntax which matters, but the semantics. Syntax is a matter of commas, quotes and colons. The bits of the language that you have to learn are the nouns and verbs, which actually do something. Compare a similar recipe in Puppet:

file { "/data/someservice.conf":
  owner  => $user,
  mode   => 0644,
  source => template("someservice.erb"),
}

I don’t see how this is less ‘easy’ than the Chef example! It looks pretty much identical to me. Compare any Chef and Puppet recipes which do the same thing and you will see they use more or less the same semantics.

The point I was trying to grapple with is the argument that “Chef is just Ruby, therefore you don’t need to learn anything new”. Even if the syntax is familar, you need to learn new semantics.

You’re right. The syntax

You’re right. The syntax comparison doesn’t even matter.

What matters is that with Chef recipes, I can reach to Ruby directly. I can make a call to an external data store like MySQL with Ruby code. I can create and use hash data structures. I can iterate over a list and create a number of resources. I understand that Puppet has a DSL now, but it is not promoted by its proponents, because it was added to appease people who wanted to use Puppet but prefer Chef’s DSL.

In the end though, the language used for writing configuration in either tool still doesn’t matter. The more important differences are ordered recipes vs directed graph, having node data storage and indexing built in, and client vs server recipe/manifest processing. These matter more to me when managing infrastructure at scale.

“I understand that Puppet has

I understand that Puppet has a DSL now, but it is not promoted by its proponents, because it was added to appease people who wanted to use Puppet but prefer Chef’s DSL.”

Completely untrue. As one of the people who pushed for its inclusion - it’s an option. An option most of our users don’t like but still an option. It wasn’t added to appease anyone. It’s always been a Roadmap idea. You won’t find anything anywhere that says “We’re never going to have a Ruby DSL” indeed a very basic one has been in the code for 3 years before the current one. I personally don’t like it and think it’s the wrong approach but some people disagree and we’re providing them with alternatives.

Chef is, in fact, just Ruby

Chef has no syntax that is not Ruby - it’s wrong to say that the example of a resource in Chef is not Ruby, it absolutely is.

Chef has semantics like any program or library does - you can’t just slap gibberish in. :) That said, we made very intentional choices about the resource syntax - you’ll note the lack of commas in the resource parameter body (they are method calls with arguments, not a single method call with a long chain of positional or hash based arguments), for example. We did that so you would learn as little of the syntax as possible to get the semantics down. I think we did a good job.

The point of the the argument is this: if you come in alone, are you going to learn a subset of a general purpose language, or are you going to learn the specialized syntax of an increasingly complex DSL? If you are going to extend the system, must you switch languages to do it?

At the end of the day, we’re talking about software written in high level programming languages - we can all implement a given feature in a huge variety of ways. Focusing on the language is a red herring - the tools diverge far above the level of a trivial declarative resource statement (but that doesn’t mean we can't have opinions about which we prefer - look at the editor wars.)

Agreed

Yes, I think Chef gets it just right. Ruby is peculiarly suited to embedding expressive DSLs. As a Ruby programmer, I love the fact that I can just write my Chef logic in Ruby. Puppet’s language is, in all fairness, rather horrible.

However, as you rightly point out, there are much more important differences between Puppet and Chef than where they place the commas and semicolons. My original point was that “Chef is better than Puppet because you don’t need to learn anything new” is a bogus argument, even if you allow that all sysadmins already know Ruby, which they don’t. You have to learn about an equal amount of semantics in either Puppet or Chef.

Programmers tend to be resistant to switching languages because they have a significant investment in learning the one they mainly use. It’s not quite the same for sysadmins, who are used to quickly learning whatever weird application-specific configuration language they need to use this week. I think that goes some way to explaining the cultural split.

However, since I love Ruby, have years of experience with it, and think everyone else should learn and use Ruby too, I naturally think it’s terrific that Chef is an extension of Ruby. I’d say if you are going to invest time in learning a programming language for configuration management, and the two tools are otherwise equally a good fit for you, I’d recommend you use Chef because your investment will also count towards learning Ruby.

okay.. but

I really don’t think that you need to know much Ruby to get started with Chef or Puppet. Further, using Chef isn’t exactly any sensible way to learn Ruby. It’s kind of like trying to learn how to swim by crossing an ocean.

Altho, with that being said, if you come from some development / programming background, learning enough Ruby to be able to use Chef (or Puppet) wont be a big deal.

I found this statement of yours to be interesting:
“Programmers tend to be resistant to switching languages because they have a significant investment in learning the one they mainly use.”

In my experience, it’s the people with a background in some lower/mid level language that can pick up new languages easily. If you know C or C++, then you already know the design patterns and algorithms and can directly implement them into these high level abstracted languages very easily. It’s just a matter of the syntax.

“What sysadmin doesn’t at

What sysadmin doesn’t at least know a little Ruby?”

The majority don’t, and don’t care to after learning C, perl, sh, and possibly Python.

We deploy and manage computing resources. Go kanban your agile scrum with a devop nosql cloud. :)

Hudson hit my Puppet with

Hudson hit my Puppet with a cucumber?

10 reasons why Cfengine wins

Those 10 reasons are among those why Cfengine wins over Puppet. First mover advantage, you say? Cfengine was born over a decade before Puppet.

Cfengine’s not part of this

Cfengine’s not part of this comparison, but I take your point. Puppet was born out of dissatisfaction with Cfengine, just as Chef was born out of dissatisfaction with Puppet.

We’ve been using cfengine for

We’ve been using cfengine for 12 years (runs after OS load and installs its own 3AM-plus-random-minutes cron job on every host). I’ve been considering Puppet for its modeling capabilities and also, well, to add it as a notch on my resume. From what I see of Chef’s dependency list, documentation, and Ruby knowledge requirement (no matter how many people from Opscode deny it) I’m really not even interested at this point. But I have to say, too, that I’m not really psyched on this graph/determinism issue though, which has been thoroughly explained by the Chef side from people who left Puppet behind because of it. I’ve yet to see any detailed answer from Puppetlabs on the topic’s validity. I think it would be pretty worthwhile for Puppetlabs to address the topic in detail (as in 6 months ago), performing their own tests as necessary, and making it clear if there is an issue, and if so what sysadmins need to know about it until it is addressed.

I really appreciate this whole thread of conversation though, no matter how weak the original blog post is (and it is, John A, it should have marinated and been developed twice as much as what is here). It’s unfortunate, however, that a LOT of points have been brought up, refuted, and died. This is great info, but it is all still a completely murky mess to sort out.

Yes, there have been a lot of

Yes, there have been a lot of comments on how poor the article is. However, around 25,000 people have read it, so I’ll live with that.

Also, I want to point, as I

Also, I want to point, as I already have to James T., that being able to build these tools from source is MANDATORY. This notion that “if you are building from source, you are doing it wrong” is a) total bullshit and b) completely vapid when you are not offering build tarballs for all OSes you claim your tool runs on. Where’s your Solaris pkg tarball? Yes, build from source. What if I want our CM shit in /usr/local/cm-tools, built with options for our environment? Yes, build from source. What if I want, as *ANYONE* should want, the Ruby used for our CM tools decoupled from the OS-provided Ruby which can change out from under me? BUILD. FROM. SOURCE. You’re rollout out a *configuration management* framework for sanity in your environment, and in the process a lot of you are doing it with the same old braindead methodology.

Configuration management software is something to be installed and LEFT ALONE unless a serious security vulnerability or bug *that actually affects your environment* is found (not talking about config changes). It is a setup effort that should last more than a year without being dicked with.

MAJOR RANT

I am *amazed* at some of the hackish mentality shown by so many people doing CM work or rollouts. On one hand, you say you “Get It” because you are doing CM instead of firefighting or meatforcing deployments. On the other hand, you cut your teeth dicking around with every latest release candidate of every Linux kernel or tool known to man and just can’t keep your hands between your ass and a chair. Listen, I *don’t want* the latest stable version of your CM tool, released 3 weeks ago, installed. I want the version I am using already, that I tested thoroughly with our environment, and that *works perfectly fine on my N-hundred boxes*. I will never, ever, stop being at odds with this “Linux Generation” of needless upgraders, let alone the ones who claim to understand system stability and interdependencies.

amen

I hate that both these tools are dependent on ruby. I love ruby for what it is but it really is not ideal for this type of work. Ruby is only supported on 32bit platforms by the own admission of the developers (all other platforms are best effort), ruby has no real stable versioning ie 1.9.1 is not compatible with 1.9.2 even though they say it is, . I’m in the process of a chef deployment and it’s been a nightmare getting ruby synced up between different OSes. God help us when we need to go to a newer distro and will have to do this ruby dance all over again. I pushed for CFengine because it stays out of the way of the OS but didn’t win, I really wish I pushed harder.

For managing different

For managing different versions of Ruby on different OSes, RVM may be your friend.

I didn’t know that the Ruby developers don’t officially support 64-bit, but I use Puppet in production on hundreds of 64-bit servers and have no problems. With older versions of RubyGems, gems can be installed to different locations depending on the architecture, but that’s become much better organised with recent versions.

rvm is not an option for rolling out stable packages

RVM is not an option, we prefer to package everything for easier deployment. Regardless I should not need multiple versions of ruby to run configuration management. This goes to my complaint of it not being stable and not really suited to this task. I cannot just compile it and run it everywhere.

System stability versus upgrades

Jeff, +1 for system stability over needless upgrades. I am still struggling to get Chef up and running on Fedora 14/15, and from my limited experience I can say that most of the problems are due to the large number of third party software used. Getting them to work together, assuming you have the latest versions (including of your distro), needs infinite patience. Get one to work, and another breaks.

In contrast, Puppet was easy to install. Puppet has an advantage in this specific aspect as it has distro specific installers, and I’m sure Chef can have that as well for all distros. But till then, it’s just a waste of time trying to get it up and running. Puppet is not without its problems though, especially certificate related ones.

I find it ironic that a tool that is supposed to hide the differences between the underlying OSes does not work on a major Linux distro.

Yea? Then try to find

Yea? Then try to find dependency cycles when you have 200 resources. You’ll be surprised to find that there is absolutely no support for doing that.

Actually there has always

Actually there has always been and it’s improved further at: http://projects.puppetlabs.com/issues/show/2597.

Serious?

After reading this post, it is clear that I would never hire this consulting company. This sounds like the typical vendor BS, and didn’t touch on the strengths of either tool. I think I am actually stupider after reading this, and this post should really be seen as an indication of just how much this company lacks a clue.

Well, you read the post,

Well, you read the post, which is the main thing. I can’t comment on whether it’s made you stupider or not (I don’t know how stupid you were to start with).

Way to stay classy.

Way to stay classy.

I would hire them

I would hire them cause they don’t BS and tell it as it is. Too many vendors sugar coat their solutions to make a sale. You do OpenStack with puppet?

This is entirely inaccurate

This is entirely inaccurate. I have bashed my head against the wall with Puppet. The documentation is THE WORST!

What’s the problem

What’s the problem you’re having?

I found puppetmasterd ate a

I found puppetmasterd ate a lot of ram. If you wanted a GUI, you have to setup foreman yourself. If I was to store facts the way I want to for all my nodes in mysql using store configs I could see my puppetmaster server to be a very high end server. I believe chef already comes with mongrel, and of course storing data into Solr which is much better. By default I can see chef could scale higher than puppet without having to configure manage my configuration management system.. which you know I would love to do.

Did we even mention knife, a client tool to interact with the CMS? How about cloud plugins? FFS I can launch Rackspace servers with roles right from my workstation.

Chef also communicates using REST rather than xmlrpc.

The Chef infrastructure is quite different and dramatically more efficient and elegant regardless of the coding structure although I do understand the dilemma.

I think I remember something in this post about reinventing the wheel. Reinventing a programming language isn’t reinventing the wheel, puppet. Rather than Opscode example, learning from puppet’s mistakes?

All the points of the post just is how Puppet is more popular because it was the first kid on the block and the growth of cloud computing needed something like this immediately so it took off.

Overall this does suck because of the higher user base and which way to go considering support. Internally I’m met with inefficient software.

Bryan

I've used both and....

I helped one of these giant companies implement Puppet, with many billable hours from reductive labs. It was implemented more-or-less company wide.

I can say, if well implemented, Puppet works. I can say that the ‘preview’ mode of puppet has solid value in catching syntax errors. But, for a ‘successful’ run, as rightly pointed out, the results of a preview are often misleading, which I will visit shortly.

Other than preview, another so-called advantage of puppet is to run it in pieces (with tags) so as not to expose your systems to puppet portions (manifests) that you don’t want or need. Ironically, this feature speaks to the tendency for the full-blown puppet run to change your system quite dramatically, often from changes submitted by groups (in remote offices and/or other continents) for their own peculiar needs.

The effort to figure out what changed can be difficult, and is actually additional work beyond introducing the change you *actually* need. Therein lies the issue with the preview. It is usually long and if you *happen* to notice something you don’t like, you have to go through the process of reconciling it. Given the nested and dependency nature of manifests, this can be painful.

Given, preview is great to see if there is a syntax error. But again, a program editor can catch a syntax error without needing to actually run or compile anything; if of course, you are using a real programming language ;-)

As others posted, you are much more likely just to give a ‘questionable’ Puppet preview an actual run anyway, and try to sort it out from the configured box. The preview is a sort of ‘heads-up’ you don’t need because the actual run logs what actually occurs.

The other problem with running in pieces is that the more often you bypass manifests (run with tags), the greater the variation from the whole run. After a few weeks, you literally have no idea what a full run will create/destroy.

Not that Chef solves many of these issues. I think my point is that the few ‘features’ of Puppet are quite negligible. But, to the point that Chef language resembles a real programming language, and a popular one that knowing can open vast opportunities for its adopters (as compared to learning Puppet language), I have to recommend not to waste your time with Puppet and just go straight to Chef.

The few benefits for Puppet with its 5 to 10 year head start are quickly vanishing, and because Ruby is more commonly supported than Puppet language, Chef should quickly supplant Puppet in terms of number of useful recipes vs manifests in the next couple of years.

To highlight my most negative experience with Puppet, the vast number of manifests you end up with using Puppet is *not* an improvement over a monolithic scripting. This is the biggest drawback of the directed graph approach. Yes, this is fixed with branches - lots and lots of branches! But, did you make things easier, safer, quicker to deploy with all of these branches? Likely not.

And, to highlight my most happy moments with Chef - the use of simple JASON statements, with or without knife is awesome. Puppet, if it knew what JASON was, would be incredibly jealous of that.

What if the users are primarily SysAdmins that don't write code?

Andrew - I have a question for you since you’ve used both.

I’m more than comfortable writing Ruby, but I’m responsible for getting CM in place and then handing it off to an admin team for maintenance. The admin team consists of 3 people, one can write decent Perl, the other 2 don’t know anything other than basic shell scripting.

I didn’t have the time to evaluate both, and went with Puppet because I thought the Puppet DSL would be easier to consume for the two admins that can’t code.

In your opinion, did I make the right choice?

Justin, I’m not JASON… I mean

Justin, I’m not JASON… I mean Andrew, but I’m in the same boat as far as coworkers’ skills. I’ve used CFEngine for ages, learned Puppet lately, and know enough Ruby to know what Chef would be like. Your situation is a hard one, as I believe none of these tools can be handed off confidently to coworkers who don’t already know some language well (and basic programming skills/concepts), no matter what fans of the tools say. Puppet’s DSL, for example, is super warty in my experience, which ends up making it just as involved to deal with (IMO) as any full language. And with CFEngine 3, to make reasonable use of it, there’s not really a lot of common programming practice that applies — you need to understand its way of approaching things (promise theory).

In our environment, it boils down to “if you don’t know the tool, don’t touch the config”. Luckily, changes to the CM tool’s policy/manifest/whatever are a once-weekly affair in the worst case. Having 1.5 people know how to do it is enough to get by.

You have to excuse my first

You have to excuse my first post. I wrote it in a text editor and copy/pasted it — I was writing the word JSON but didn’t notice spell-check switched it to JASON, lol! Just typing in the silly box now… nothing fancy… okay, I ‘wish’ I had some cfengine experience so I could give you feed back on that (if you believe that, I have a bridge to sell you). I can tell you I wrote my own configuration management tool in TCL/Tk (for the database and front-end piece) about 5 years prior to moving to Puppet. That tool was NOT replaced by Puppet. In fact, the software I wrote may very well outlive puppet — why? Because the TCL/Tk front-end is a heavy user of basic shell scripts on the back-end. And, the database is a series of simple multi-column flat-files (don’t get me started on couchdb and rabbitmq). Literally, the most junior admins can figure out how to type commands, echo them to a file, and voila - a shell script for the back-end. And, fixing the database? Just vi the flat-file! So, I have found that these modern tools are, I agree, way overly complicated and rely too heavily on great programming skills as well as DB skills. And, that can be expensive, not just in labor costs but programming time and db management. What are the options? Not many. So, we have to look to adopt easier languages (ruby/json in Chef) with an eye towards long-term supportability. Otherwise, no reason not to go back to using shell scripts in a while loop.

the 'right' decision is usually a trade-off...

I am not a Puppet ‘hater’ as much as a Chef ‘admirer’. I think Ruby is far easier than Perl, for instance. And, as far as Puppet DSL, it looks similar to an actual JSON. So, it is probably a draw today, and you made the ‘right’ decision considering everything else you have to juggle. However, what about tomorrow? This is where senior admins and managers have to make the tougher decision — ease of adoption today vs. longevity and usefulness tomorrow. Specifically, what if the Puppet DSL goes unsupported in a few of years? You get stuck with primitive statements and inability to expand to handle new technologies and years of manifests can go wasted. Ruby is far less likely to meet an early demise compared to Puppet DSL. Since Puppet DSL coding can look similar to JSON, why encourage staff to learn a ‘fake’ language when they can learn a real one? And, what is a RALSH? Do you want to put all your enterprise eggs in that basket? In that sense, I stick by my advice: skip Puppet, Puppet DSL, and RALSH, and go for a modern and much more supportable methodology in ruby, knife and json found in Chef.

puppet --help barfs!!

This is my day one with Puppet. I managed to install it. When I type ‘puppet —help’ I get

/usr/lib64/ruby/site_ruby/1.8/puppet/util.rb:211:in `absolute_path?’: undefined method `features’ for Puppet:Module (NoMethodError)
from /usr/lib64/ruby/site_ruby/1.8/puppet/util.rb:189:in `which’
from /usr/lib64/ruby/site_ruby/1.8/puppet/util/command_line.rb:85:in `execute_external_subcommand’
from /usr/lib64/ruby/site_ruby/1.8/puppet/util/command_line.rb:70:in `execute’
from /usr/bin/puppet:4

So much for maturity!!

I hope it works well when everything is configured properly.

Puppet v. Chef (From some dude now trained in both.)

(FYI: I posted something similar recently but figured my experience is recent so it’s worth saying.)

I just spent a few days in the official OpsCode training that was brought in-house, what I have to say, is opinion which you can take with a grain of salt. My experience is having built out the foundation of a deployment system for a very large retailer in North America, and we built this using puppet. Most of the things that people consider a plus of chef over puppet we found a way to do in puppet.

The only thing I could help thinking during that training (OpsCode), “where is the value add here, I have heard Chef uses JSON and has all of this ‘stuff.’” Well, first off they don’t condone using couchdb any longer, I thought that would be a +, not so much, secondly - they still suggest (not directly of course) that the server doesn’t matter, and didn’t even touch on what to do with the client server model, that bothers me - I like a central location that can basically “control” all of my nodes, it’s great the nodes can make a decision on what they want to be by themselves but is that really what we want as systems engineers. Further, in all honesty is that what you want in the heat of battle when you are dealing with a spike in usage and you want to deploy X number of servers in a small time frame that are supposed to specifically do Y job? I’m not sure, I’m not sold - I am kind of disappointed that the higher level methods that were taught in the class were basically ruby embedded inside cookbook recipes.

Lastly, in my non-work life I do a tremendous amount of work supporting small dev shops. For part of this I use a non-Debian/RedHat home rolled cloud solution. Building the chef server has taken weeks, whereas puppet client/server was up and running in hours. Even when I thought the worst of the chef server build was over it wasn’t - in they end they use what I think is fairly obscure library (gecode) that only compiles on a couple of platforms. I don’t know, from my perspective - even if you already know Ruby you can leverage that with puppet, it shouldn’t be your selling point - and if you are a developer looking to build out a scalable architecture you may want to talk to a systems engineer or two.

Just some background on me, I am not a religious person when it comes to tools or solutions, I have always been an advocate of the right tool for the right job. I went into the training thinking ‘this is the right tool for this place.’ After walking away from a couple days of it - it’s definitely not the tool I would ever suggest to anyone trying to build out to scale. I guess this is why the likes of Google, NASA, Stanford, etc., use puppet - sure Chef is Ruby, but the goal is to replace home-rolled / or no tools not build new ones.

More like 3 reasons

You have three reasons:
1) It’s more used/more mature (reasons 1, 2, 4, 5, 8, 10)
2) It doesn’t use Ruby (reason 3)
3) More broadly useful (reasons 6 and 7)

SaltStack is a new promising

SaltStack is a new promising choice: http://docs.saltstack.org/

Alternative to Puppet or Chef

Hello,
My name is Alicia and I work for a small tech start up, dotConfig, based in the San Francisco Bay Area. I have read over your article, Puppet versus Chef: 10 reasons why Puppet wins, and I would love speak to you about possibly featuring our company’s product. dotConfig is a realtime configuration management software which is transparent, easy and efficient. I look forward to speaking with you about a possible feature on your blog.

Regards,

Alicia

alicia@dotconfig.net

Derp

The Puppet server can run on any platform which supports Ruby”.

…Chef doesn’t really offer anything new which would make it worth switching”

The author of this post *desperately* needs to learn the difference between “that” and “which”.

Fair point!

Fair point!

Eh

I’m neither a chef nor puppet fanboy - I am starting out and weighing my options — but I have to say, 5 of your reasons are “use it because more people are using it .. use it because everyone else is!”. I’m not sure that is what is going to drive everyone to flock to puppet :) Support and community is important, however just because something is widely adopted doesn’t mean it’s worth a damn.

Ansible

You should definitely check out Ansible (http://ansible.cc/). It’s the new kid on the block, it’s a viable alternative with some compelling and unique features. Multi-tier orchestration, complex inventory and flexible provisioning and the most compelling reason “learning it took me 20 mins”

Rex

Hi,

there is another powerful Tool which is called (R)?ex (http://www.rexify.org/) !

It’s written in Perl and you have to use Perl for the Configtasks.
I think there are more Sysadmins with Perl background as other languages. Isn’t it ?

Regards,
 Sascha

No s390x support for puppet

A big reason puppet loses here, is there no support for s390x platforms.

yet more poo

Is chef and puppet for people who don’t grasp kickstart and bash and just Linux basics ?

Many years ago we used a cvs repository to create machine configuration files
that was available as a NFS share when we deployed Linux boxes from
bare bones . When the server boots the first time, it mounts the share,
and locates it’s configuration based on host name or other unique id,
and checks out the latest config scripts. Note that cvs was the forerunner
of svn.

I really can’t understand why people are drawn to an ugly language like
ruby either.

Ancient article

This article is ancient… 4 years old. Puppet lost.

Chef for AIX 5.3

Can chef be installed on AIX 5.3…??

Post new comment

The content of this field is kept private and will not be shown publicly.
CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters shown in the image.
By submitting this form, you accept the Mollom privacy policy.