3719448961_6393fa69d2In traditional data centers, server configuration and management was the purview of system administrators. They lugged around the servers, hooked them up to power and networking infrastructures, and installed and configured the software and services required of them by clients.

For the most part, that’s still how data centers are run, except for the last part of the process: the configuration and management of server operating systems and other software.

As companies like Google and Facebook found they needed ever quicker and more agile server provisioning, they automated much of the process, developing programmatic tools that made server configuration more akin to development than traditional server administration. So began the rise of devops, which applies the techniques of development to system administration tasks.

Over the last few years, two tools have gained prominence in the devops world: Chef from OpsCode and Puppet. Both are configuration management tools created to allow for the programmatic configuration and management of multiple servers. There are however significant differences between the two.

The most obvious difference between Chef and Puppet is one of language. From a certain perspective, Puppet is a language – a declarative language with similarities to JSON – and the tools to implement that language’s instructions. OpsCode Chef on the other hand uses a subset of the popular Ruby language to create a domain specific language. Chef recipes are written in Ruby using helper functions that are part of Chef.

They also differ in that Puppet has dependency resolution at the resource level while Chef does not. While that might appear to advantage Puppet, in fact for many applications it unnecessarily increases complexity. Chef does not make assumptions about the environment in which it is running, trusting that the team involved in a project will have the understanding necessary to design recipes to suit their needs. It will then execute those recipes with identical results: Chef operations are entirely deterministic and predictable.

Chef also has the advantage of being designed from the ground up to integrate closely with other tools. And that’s part of what makes it an excellent tool for orchestrating configuration management in multi-cloud environments.

As is probably obvious from the above: devops tools like OpsCode Chef are perfectly suited to the cloud environment. The cloud is a programmatic abstraction of server hardware and infrastructure resting on top of virtualization technology. Configuration management tools are ideal for deploying and managing cloud servers, storage, and software.

Among the advantages to using OpsCode Chef for multi-cloud orchestration are:

  • Lower Barrier To Entry – OpsCode Chef uses Ruby natively, a language that is familiar to many and can be easily picked up by anyone with some development experience. Puppet on the other hand uses a declarative language which will not be familiar, either in its specifics or its concepts to most modern developers. While Puppet does implement a Ruby-based domain specific language, it demands users implement dependency graphs, which makes it more complex from the user perspective.

  • Excellent Integration With Cloud Services – Using the Knife Plug-in architecture, OpsCode Chef can be easily hooked into many different cloud environments. It’s the perfect choice for multi-cloud environment where companies want to distribute resources across different cloud vendors.

Using OpsCode Chef for multi-cloud configuration and management helps reduce management complexity, puts more options in the hands of developers, and helps users leverage the full benefits of a multicloud marketplace.

 

  • Adi Chiru

    I am not sure why was this article written as I can’t find a real comparison between the two tools. Also Chef and Puppet are NOT orchestration tools and they are still very bad at orchestration, unless you change the definition of that…. which is what some are trying to do currently….