Utility computing is a business model that allows operators of applications to run their applications without owning or operating computing hardware.

Like the early days of electricity, when companies had to have their own generators, the first ten years of the internet era have required businesses to own and operate servers. Of course, most companies aren’t in the IT business, so running a server isn’t any more an integral part of their business than running a generator for their electricity but there wasn’t an alternative. Then, in the midst of the dotcom bubble, several hardware vendors began talking about a new way to purchase resources - utility computing.

In concept utility computing is simple; rather than purchase and operate servers themselves, businesses subscribe to a computing utility. Just as you use electricity without owning the equipment that creates it, subscribers would utilize computing resources (CPU, memory, storage and connectivity) without owning hardware. They would build applications precisely as they do today but be able run them without concern for how the resources are provided and simply pay for what they’ve used.

I’ll leave it to you to start threads discussing whether any of the vendors who helped coin the term utility computing have actually achieved the vision. However, whether they have or not doesn’t impinge on the fact the vision is compelling.

Enough marketing hyperbole, the definition of utility computing is any system having the following characteristics:

• access to the system is ubiquitous
• subscribers can begin using the system without expensive hardware or software
• subscribers can create and run applications of arbitrary size at any time
• subscribers can use the utility to run any kind of applications they want
• subscribers can change the amount of resources used by a running application
• resources are paid for only as they’re used
• subscribers can terminate service without exorbitant cancellation fees

The rationale for each requirement follows naturally from our experience with traditional utilities like electricity, telephones, water and gas. For instance requiring service from a provider to place an application on the system or to start/stop it would be much like using an operator to place a call. Yes, it used to be that way, and phone service was expensive because of it.

Some of the implications of these requirements may not be immediately apparent. For instance, in order to allow users to start applications and change the amount of resources they’re allowed to use, the basic unit of resource must be generic. A server, a CPU, a MB of storage are all generic enough to be aggregated. However, trying to specify CPU model, cache size, front side bus speed, or disk drive interface will create impediments to service. This isn’t a step taken lightly because most users have spent a great deal of time dealing with such options in configuring servers in the past, but consider the implications if such a model is carried forward. The number of possible permutations goes up geometrically with the number of specifiable parameters. Therefore, with just a handful of choices a utility service would have to carry dozens of different configurations and the probability that such a resource isn’t available when your process needs it also goes up geometrically. Specifying only generic resources allows those resources to be offered efficiently and cheaply and you can simply purchase more of them at the lower cost.