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 which 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 which 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 which 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 which 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 which would make it worth switching.
Of course, Puppet itself reinvented a lot of functionality which 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.
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
Is this one of those ‘Mine is advocacy, yours is propaganda’ things?
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
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!
Chef has more contributors than Puppet.
http://www.ohloh.net/p/compare?metric=Contributors&project_0=Puppet&proj…
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
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
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.
Post new comment