Most of us have tried to solve these problems of configuration management in various ways. Some write shell scripts to automate builds and installs, some use makefiles to generate configurations, some use templates and disk images, and so on. Often these techniques are combined with version control, to solve the history problem. Systems like these can be quite effective, and even a little bit of automation is much better than none.
The disadvantage with this kind of home-brewed solution is that each sysadmin has to reinvent the wheel, often many times. The ways in which organizations solve the configuration management problem are usually proprietary and highly site-specific. So for every new place you work, you need to build a new configuration management system (CM system).
Because everyone has his own proprietary, unique system, the skills associated with it aren't transferable. When you get a new job, all the time and effort you spent becoming a wizard on your organization's CM system goes to waste; you have to learn a new one.
Also, there's a whole lot of duplicated effort. The world really doesn't need more template engines, for example. Once a decent one exists, it would make sense for everybody to use it, and take advantage of ongoing improvements and updates.
It's not just the CM system itself that represents duplicated, wasted effort. The configuration scripts and templates you write could also be shared and improved by others, if only they had access to them. After all, most server software is pretty widely used. A program in configuration language that sets up Apache could be used by everybody who uses Apache—if it were a standard language.
Once you have a CM system with a critical mass of users, you get a lot of benefits. A new system administrator doesn't have to write his own CM tool, he just grabs one off the shelf. Once he learns to use it, and to write programs in the standard language, he can take that skill with him to other jobs.
He can choose from a large library of existing programs in the standard configuration language, covering most of the popular software in use. These programs are updated and improved to keep up with changes in the software and operating systems they manage.
This kind of beneficial network effect is why we don't have a million different operating systems, or programming languages, or processor chips. There's strong pressure for people to converge on a standard. On the other hand, we don't have just one of each of those things either. There's never just one solution that pleases everybody.
If you're not happy with an existing CM system, and you have the skills, you can write one that works the way you prefer. If enough other people feel the same way, they will form a critical mass of users for the new system. But this won't happen indefinitely; standardization pressure means the market will tend to converge on a small number of competing systems.
This is roughly the situation we have now. Several different CM systems have been developed over the years, with new ones coming along all the time, but only a few have achieved significant market share. At the time of writing, at least for UNIX-like systems, these CM systems are Puppet, Chef, and CFEngine.
There really isn't much to choose between these different systems. They all solve more or less the same problems—the ones we saw earlier in this chapter—in more or less the same way. Some people prefer the Puppet way of doing things; some people are more comfortable with Chef, and so on.
But essentially, these, and many other CM systems, are all great solutions to the CM problem, and it's not very important which one you choose as long as you choose one.