Puppet versus Chef: 10 reasons Puppet wins
In this blog post, John Arundel of Bitfield Consulting outlines how Puppet stacks up against Chef and other tools. John is a well-known Golang trainer and mentor, Kubernetes consultant, and Puppet expert and author. Say hello@bitfieldconsulting.com!
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.
Update: this piece was originally published in 2010, and many things about the landscape have changed, including the decline of Chef and the rise of Ansible. However, I retain it here for historical interest, and I still think Puppet is the best choice, even ten years later.
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 Beginner’s Guide book.)
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.
