This problem is called configuration management, and thankfully we don't have it with a new laptop too often. But imagine multiplying it by fifty or a hundred computers, and setting them all up manually.

When I started out as a system administrator, that's pretty much what I did. A large part of my time was spent configuring server machines and making them ready for use. This is more or less the same process as setting up a new laptop: installing software, licensing it, configuring it, setting passwords, and so on.

Let's look at some of the tasks involved in preparing a web server, which is something sysadmins do pretty often. I'll use a fictitious, but all too plausible, website as an example. Congratulations: you're in charge of setting up the server for an exciting, innovative social media application called cat-pictures.com.

Assuming the machine has been physically put together, racked, cabled, and powered, and the operating system is installed, what do we have to do to make it usable as a server for cat-pictures.com?

That's a lot of work. It may take a day or two if this is the first time you're setting up the server. If you're smart, you'll write down everything you do, so next time you can simply run through the steps and copy and paste all the commands you need. Even so, the next time you build a cat-pictures server, it'll still take you a couple of hours to do this.

If the live server goes down and you suddenly need to build a replacement, that's a couple of hours of downtime, and with a pointy-haired boss yelling at you, it's a bad couple of hours.

Wouldn't it be nice if you could write a specification of how the server should be set up, and you could apply it to as many machines as you liked?

So the first problem with building servers by hand ( artisan server crafting, as it's been called) is that it's complicated and tedious and it takes a long time. There's another problem. The next time you need to build an identical server, how do you do it?

Your painstaking notes will no longer be up to date with reality. While you were on vacation, the developers installed a couple of new Ruby gems that the application now depends on—I guess they forgot to tell you. Even if everybody keeps the build document up to date with changes, no one actually tests the modified build process, so there's no way to know if it still works end-to-end.

Also, the latest version of MySQL in the Linux distribution has changed, and now it doesn't support some of the configuration parameters you used before. So the differences start to accumulate.

By the time you've got four or five servers, they're all a little different. Which is the authoritative one? Or are they all slightly wrong? The longer they're around, the more they will drift apart.

Wouldn't it be nice if the configuration on all your machines could be regularly checked and synchronized with a central, standard version?

The latest feature on cat-pictures.com is that people can now upload movies of their cats doing adorable things. To roll out the new version to your five web servers, you need to install a couple of new package dependencies and change a configuration file. And you need to do this same process on each machine.

Humans just aren't good at accurately repeating complex tasks over and over; that's why we invented robots. It's easy to make mistakes, leave things out, or be interrupted and lose track of what you've done.

Changes happen all the time, and it becomes increasingly difficult to keep things up to date and in sync as your infrastructure grows.

Wouldn't it be nice if you only had to make changes in one place, and they rolled out to your whole network automatically?

A new sysadmin joins your organization, and she needs to know where all the servers are, and what they do. Even if you keep scrupulous documentation, it can't always be relied on. In real life, we're too busy to stop every five minutes and document what we just did.

The only accurate documentation, in fact, is the servers themselves. You can look at a server to see how it's configured, but that only applies while you still have the machine. If something goes wrong and you can't access the machine, or the data on it, your only option is to reconstruct the lost configuration from scratch.

Wouldn't it be nice if you had a configuration document which was guaranteed to be up to date?

Ideally, all your machines would have the same hardware and the same operating system. If only things were that easy. What usually happens is that we have a mix of different types of machines and different operating systems and we have to know about all of them.

The command to create a new user account is slightly different for Red Hat Linux from the equivalent command for Ubuntu, for example. Solaris is a little different again. Each command is doing basically the same job, but has differences in syntax, arguments, and default values.

This means that any attempt to automate user management across your network has to take account of all these differences, and if you add another platform to the mix, then that further increases the complexity of the code required to handle it.

Wouldn't it be nice if you could just say how things should be, and not worry about the details of how to make it happen?

Sometimes you start trying to fix a problem and instead make things worse. Or things were working yesterday, and you want to go back to the way things were then. Sorry, no do-overs.

When you're making manual, ad hoc changes to systems, you can't roll back to a point in time. It's hard to undo a whole series of changes. You don't have a way of keeping track of what you did and how things changed.

This is bad enough if there's just one of you. When you're working in a team, it gets even worse, with everybody making independent changes and getting in each other's way.

When you have a problem, you need a way to know what changed, and when, and who did it. Ideally, you could look at your configuration document and say, "Hmm, Carol checked in a change to the FTP server last night, and today no one can log in. It looks like she made a typo." You can fix or back out of the change, and have Carol buy the team lunch.

Wouldn't it be nice if you could go back in time?