There has recently been a huge growth in the number of Configuration Management (CM) tools available to the sysadmin or DevOps professional. Well, ‘huge growth’ really means an increase from just 2 or 3 in the early 2000’s (CFEngine comes to mind as one of those early pioneers), to about 20 today. Many of these are little-known niche products, but some bigger names like Chef have passionate adherents, and equally passionate detractors.
Let’s compare Chef to Pallet, a relative newcomer in the CM market. There are a few important differences between them if they both make your shortlist, but they are also very similar in other ways. Using either of them will still be a major win for you. It’s the CM equivalent of owning no TV then having to choose between a Samsung 55-inch 3D screen and a Sony 60-inch 2D; whatever your decision criteria are - screen size, 3D or not, manufacturer - you’re still getting to choose between 2 great options that were both unavailable just a few years ago.
Chef and Pallet are both open-source CM tools. Beyond that though, we can classify CM tools into two general groups: those tailored towards sysadmins and those tailored towards developers. The guy selling you the solution won’t tell you about this distinction, of course, but reading articles like this one and researching the blogosphere and discussion forums will inform you which side each app leans more towards.
Now, Chef and Pallet can be considered to be geared more towards developers and perhaps devops than pure sysadmins. This is because of:
Their modus operandi. In developer-centric CM tools, you typically script and define in detail what needs to be done on the server, and the tool runs these steps in parallel on all the hosts you have defined. But admin-centric tools work by defining the state in which you want a certain group of nodes or hosts, and then the tool executes the necessary actions, simultaneously or sometimes asynchronously, to get all the nodes into this desired state.
Their heavier reliance on code and the CLI rather than the GUI. In fact one doesn’t even host a GUI, and the other one isn’t particularly well-developed compared to a tool like Puppet or Microsoft’s SCCM.
Their use of pure base-language syntax instead of derived DSL’s in the CLI. This indicates a procedural rather than model-driven mentality, and it is a dead giveaway because it clearly shows a preference for flexibility and power (preferred by developers), rather than simplicity and efficiency (preferred by sysadmins).
Pallet was rolled out in 2011, and is not strictly a standalone CM tool, but a DevOps framework or set of libraries that can be embedded into other applications. Pallet can be considered the purest expression of the infrastructure-as-code philosophy behind all CM tools. It is a stripped-down, essentials-only tool targeted heavily at cloud infrastructure rather than the data center. Even the parent company’s home page is thick with pointers to this, like “Create a Hadoop cluster on Amazon EC2 in 5 minutes” and “List of Supported Cloud Providers”. It is supported on a number of leading cloud providers – Amazon EC2, Rackspace, Virtualbox, GoGrid, etc. It uses Clojure on a JVM, and usefully includes native support for clusters, node dependencies and agile development; actually Clojure is itself a JVM interpretation of the LISP language. Pallet does not have a GUI, all actions are scripted in the CLI.
Chef is an older tool, first released in 2009 and supported by parent company Opscode. It uses pure Ruby in the CLI, but also has a relatively well-developed GUI, although it pales in comparison to a powerful GUI like Puppet’s. Chef uses a master-agent setup, in which a central master server coordinates and sends out instructions to a number of agents installed on all other client nodes. The agents can even be installed from the client side using the ‘knife’ tool and SSH for easy deployment. A glaring omission in Chef is the lack of proper support for push deployments; the agents can only ‘pull’ new instructions by periodically checking in with the master. So you can’t deploy changes instantaneously, you have to wait until the next scheduled timeslot when the agents dial back home. Continuing with the kitchen metaphor (‘knife’), Chef configs are packaged into JSON files called ‘recipes’, prepackaged templates sharable on the net are called ‘cookbooks’, and the software can run in client-server (called ‘Chef-server’) or standalone mode (called ‘Chef-solo’). Sounds cool, you may suppose, but others have complained this metaphor just results in forced pun-names instead of truly helpful feature descriptors. And Chef’s documentation and general format makes it difficult for a newbie to get started with it.
Community & Support, Platforms, Pricing
Chef, being much larger and having been around for longer, unsurprisingly has a much larger user community and better corporate support. There is a comprehensive documentation set and a vibrant user community, including various IRC channels. Chef is open-source software, so there is a free version. Opscode/Chef also offers an enterprise version and charges range from $120 per month for 20 servers to $600 per month for 100 servers. It is available for Linux, Unix and Windows environments, although the Windows support could use some improvement.
Pallet is a much newer app than Chef, so the user community is still tiny and support from parent PalletOps still limited. The PalletOps team concede that their documentation is still developing, given the number of basic questions that still puzzle users, and they are working on improving it. It is still an open-source tool, there is no commercial version yet, and it is currently only available for Linux and Unix. Again, Pallet is still young, and even Chef was once a bare-bones tool, so improvements are to be expected as Pallet matures.
So Chef or Pallet? Only you can answer this question. Look at your needs and the main problem you’re trying to solve in your environment, create a list of must-have features (eg “My environment is mainly Windows”, which rules out Pallet for you) and nice-to-have features. Then look at which option suits your needs best.
Some caveats regarding both solutions – as mentioned previously, they are both tailored towards developers, so if your needs are mostly sys admin work you may want to consider other tools like Puppet, Salt and Ansible. Also, both Chef and Pallet will force you to first be relatively proficient in their base languages (Ruby and Clojure) to use them well. Also refer to the pros-cons chart below. Happy decision-making!
Lightweight, flexible solution.
More mature solution.
Can be embedded in other applications.
Larger community, with a large collection of modules and configuration recipes.
Ties users to Clojure, JVM.
Support for Windows (sort of), Linux, Unix.
Only available for Linux/ Unix.
Ties users to Ruby.
Still very new, so support, documentation and community help are poor.
Doesn’t support push.
Still very new, so support, documentation and community help are poor.
Relies on JSON which is not as friendly as YAML.
Not easy to learn and deploy, especially for newbies.