In the UNIX world, where there is a strong tradition of using simple tools that each does only one job, but does it well, you develop a particular sensitivity to occasions where the wrong tool is being pressed into service to do a job for which it isn’t suited.

I believe a good approach to understanding the frustration with the current tools used for configuration management can be found by considering the variable rates at which different types of data changes and the type of tools that we use to manage that data as a result of its rate of change.  Where frustration occurs, it’s usually a case of the wrong tool being used for the task.

First let’s take a typical computer system and split it into four different types of data: the base operating system; the application layer (a.k.a. middleware), the configuration layer and the user data (database records, html files etc.). These data types broadly sit on top of one another, from the base operating system upwards and they change at different speeds. A base operating system will change relatively slowly (let’s say we apply updates every six months or so),  while at the other end of the speed scale, user data can be changing by the second (e.g. database writes).  Finally we have applications and their configuration data changing at rates somewhere in between.

I’ll illustrate this with a simple table which shows the type of data, its rate of change and a typical tool used to manage that data:

Data Type Rate of Change Management Tool
Operating System Very Slow Imaging
Applications Slow Package Manager
Configuration Medium ????????
User Data Fast Backup

The dearth of dedicated tools for configuration management results in other tools being pressed into service – enter frustration.

The very slow speed at which operating systems change means that we can use imaging tools to manage those changes; each image takes a relatively long time to prepare but is fast to deploy as all you have to do is copy the bits. When these tools are used to manage a system’s configuration (or applications for that matter), the data changes so rapidly that we spend our time cutting new images and merely swap a configuration management problem for an image management one.  Same goes for package managers, to try and manage system configuration using package management tools is an exercise in futility.  In other words: wrong tool for the job.

User data, on the other hand, changes so fast that we can’t afford a tool which involves any manually intervention at all. All we want to do is blindly take a copy of the data such that we can restore it later if we have to. We don’t need to know what the data is and the backup process involves no exposition or authorisation of the changed data. If we attempt to use backup tools to manage configuration data, we will suffer from the tool’s crudeness and, although we will be able to capture and restore our configuration data, we will remain blind as to what that data is and how it is changing, an ignorance we can ill afford.  Again: wrong tool for the job.

Thankfully, we are now seeing the emergence of dedicated configuration management tools such as puppet and chef.  These tools allow changes to be made to multiple systems with a speed that (even after all the necessary change management and testing processes have been wrapped around them) feels proportionate to the rates at which data itself needs to change.  And unlike backup tools, they force us to understand our environment by explicitly declared how it should be, thus serving as a training, exposition and documenting tool in addition to just configuration management.

I’ll save the details of puppet and chef for later posts, but I’ll say that the sensitivity to the wrong tool being used that I mentioned at the start of this post also works the other way.  You know a tool is fit for the job because it just feels right when you’re using it.  Puppet gives you that feeling.

< Back