“What should I use – Puppet or Chef?” This is a common question in the mind of every developer dealing with configuration management space. While both of them are almost similar, there are some key features that differentiate them from each other, which makes even difficult for developers to make the right choice. So, let’s take a quick look at both of them.

Language

While Puppet uses a custom language, Chef utilizes Ruby. Now this is a catch, as Chef will be of course preferred by Ruby developers as it will give them the advantage of a familiar language. Puppet’s language is simplistic and often quite elegant, where as Chef is a pile of really powerful functions, methods and arrays.

Documentation

Puppet owns a large base of Wiki with hundreds of pages of documentation and comprehensive references for both the language and its resource types. On the flip side, Puppet has tutorials which are not so easy to use, at least now, due to scattered information bits.

Cookbook Flow

Puppet evaluates all manifest files, and then runs it in whatever order it deems best to ensure that the requirements are met. Talking about the Chef, it l simply does things in whatever order it’s defined, running top to bottom through each of the cookbooks.

Use Cases

As Puppet is not limited to Rails, it has a broader case, because whatever you’re trying to manage with Puppet, you’re likely to find that someone else has done the same and can help you. On the other hand, Chef has a limitation in this area.

Support Platform

Puppet supports multiple platforms, and its server can run on any platform which supports Ruby, and it can run on relatively old and out-of-date OS and Ruby versions. Chef supports fewer platforms than Puppet as it depends on recent versions of both Ruby and CouchDB. To sum up, both Puppet and Chef can deploy all domains of your infrastructure, provided it’s on the supported list.

So, having discussed most features and aspects of Puppet and Chef, which one you will choose?