In the first post, I shared my two cents on the added value of Rightscale, while in the second post I discussed Amazon's own Cloudformation. Now (a bit later than planned due to personal reasons), another piece of the puzzle, which is Opscode's Chef configuration management framework.
To make things clear from the start, I am a big Chef fan. It is a hugely powerful framework to manage a (large) set of infrastructure components and provide sufficient abstraction to achieve high productivity and enough flexibility when and where it matters.
But one step back. This is supposed to be about cloud management solutions, and while Chef has been designed with Cloud in mind, it is not necessarily a cloud management solution. It is perfectly suitable in a more traditional environment, either with virtualised or physical servers.
And in comparison with the likes of Rightscale, this is no comparison. With Rightscale you are able to define your cloud environment, such as which servers, networks, scaling algorithmes and so on, and Chef is not really focused on this. Sure, it can do certain things, but it really excels in combination with other tools that take care of the management of cloud resources. So a combination of Chef + Rightscale, Chef + Cloudformation (my preferred choice) or for that matter even combinations like Chef + Vagrant.
In the Management Stack, Chef (and for that matter its counterparts like Puppet or CFEngine) has a strong focus on the upper two layers, Server Provisioning and Service Orchestration.
Chef provides strong concepts like Roles, Environments and Data bags to design and implement a clean and maintainable configuration management solution. The primitives as provided by the framework allow for a much more declarative approach rather than the procedural approach as seen in the classic shell scripts. This is not to say that Chef based solutions are declarative by nature, as more complex functionality can be provided by programming Ruby, and then you end up with a more procedural solution after all.
Traditionally, and still often used are using pre-defined images and launch them whenever needed. However, the big advantage of using something like Chef are:
- It is Execution environment independent. It can manage resources in the cloud, on your local network as well as on your desktop.
- It is relatively platform independent, although it takes a significant amount of effort to develop and test it.
- It allows you to use clean base images, which can be updated with the latest security patches and other stuff, while it doesn't affect the configuration management solution itself.
- Running server instances can be easily updated by running the agent again.
- Chef provides much more flexibility when it comes to combining and splitting roles. E.g. for development and test purposes you would like to have combined web and database server, while for production purposes these must be separated.
Apart from managing individual servers, Chef also provides tools for composing these individual resources to a meaningful solution. For instance, web servers need to know where to find the database server, and all servers must be configured to forward their syslog messages to a particular loghost. Quite often this information is only available at runtime, and by keeping a central repository of all nodes and their configuration data, Chef allows you to query this repository and use the results in your configuration tasks.
Is it perfect? Far from it. Customising resources and keeping them separate from 'standard' resources requires quite a bit of discipline. The command line is clunky at times and for sure Chef is a complex beast. So we will celebrate a lot of improvements in the coming years, that is for sure. But for now, it is one of the most powerful solutions in this space, and I am very happy to use it.
This concludes my 2013 'State of the Cloud Management space' mini series. One of the nicest thing about our job is that it will be probably outdated the minute I hit the Publish button. And that there will be many different and non-compatible views about this subject. Let me know!
This concludes my 2013 'State of the Cloud Management space' mini series. One of the nicest thing about our job is that it will be probably outdated the minute I hit the Publish button. And that there will be many different and non-compatible views about this subject. Let me know!
