Why is Utility Computing taking so long to arrive?

Most of the major hardware vendors - including IBM, Sun and Hewlett-Packard - offer some form of physical infrastructure for utility computing already (such as HP's Utility Data Centre). But in order to work, utility computing requires a coordinated effort between hardware, applications and management software that can perform tasks such as tracking pools of computing resources. The hardware and management software has arrived, at least in early forms, but it's all still largely in the trial stage for many enterprises. And getting a company ready for utility can take some serious effort.

In today's typical non-utility scenario, a user places a request with an application on a departmental server. The server takes the request and returns the answer, then goes on to other requests. If no other requests are in the queue, the machine sits quietly and acts as a hyperexpensive space heater.

With utility computing (at least in its endgame form), that departmental server may go away entirely, usurped by a collection of machines centrally controlled by the IT department. This could be accomplished either by physically replacing remote servers with a centralized larger server, cluster of smaller servers or rack of blade servers, or by binding the remote systems into a "grid". (For definitions, see "A Glossary of Utility Terms", page left.) When the user makes a request, a series of questions must be answered by the utility infrastructure, determining what resources the user gets from the pool while tracking usage for billing purposes.

Such a level of flexibility and tracking requires management tools that are currently in their infancy, which explains why not every company is jumping on the utility bandwagon (basing your company's IT life on a bunch of relatively untried tools is only for the very brave or the foolhardy). But the real hold-up for utility computing is that application providers have yet to move en masse toward UC-ready licensing models. "The software licensing models in particular are currently the barrier to utility pricing models," says Corey Ferengul, senior vice president at Meta Group. Ideally, utility computing pricing models would allow customers to pay "by the sip", much as we do with electricity and water. But software vendors are still predominantly selling their products on a per-seat or per-CPU basis, regardless of how much or how little an individual seat or CPU is utilized.

Vendors are reluctant to move to utility pricing for several reasons, with fear being the biggest factor. A large migration to utility pricing would likely change the Wall Street valuation of software companies dramatically - almost certainly on the downside as vendors would no longer be able to book projected future revenue, but instead could claim only what they collect each month. Utility computing also promises to make it easier for companies to switch software vendors, encouraging healthy competition and reducing margins.

But Ferengul notes that smart software vendors could eventually take advantage of what may look like a bad situation, moving to a utility pricing model and locking in customers despite utility's touted flexibility and ease of vendor switching. "[With utility computing] my goal would be to deploy quickly, in hours or days, not weeks, months or years," Ferengul says. "You're not going to stop and evaluate vendors every time."

And like it or not, utility will arrive, he adds, with hardware vendors pushing it as the new model for delivery, and users pushing for software models that match their hardware.

How do I cut through the hype to realize the promise?

Ask any IT vendor if they have products for utility computing, and they'll likely say yes. But believe it or not, they won't always be telling the truth. Here are two common misconceptions:

It's more than outsourcing. Handing over your entire data centre to an outsourcer and paying it to run your applications on its servers is not utility computing. The key to utility is per-use pricing. Few outsourcing deals offer this option; IBM's much ballyhooed, 2002 multibillion-dollar deal with American Express is a notable exception. If your users don't utilize any computing resources for a month, and you still get a bill from your outsourcer, it's not really utility.

It's more than virtualization. Virtualization is the act of consolidating server power and storage space into shared pools. In a virtualized system, you may not know exactly what machine is running your database query or on what disk your quarterly report is stored. Those details are handled by software. This is a big step toward utility, but it doesn't go all the way. In an ideal world, UC allows IT departments to bill users for exact usage - per minute, per transaction or the like. Determining exactly what those units should be is one of the big questions that remains to be answered.

That's not to say that some companies won't opt for the completely external model. When American Express outsourced $US4 billion worth of IT operations to IBM, the transaction was hailed as possibly the first large-scale utility computing arrangement. In reality, the deal was remarkably similar in scope to any other multibillion-dollar outsourcing arrangement. What differed wasn't the technology, but the pricing model. Instead of paying a flat rate, AmEx would in some cases pay only for usage, providing significant cost savings. AmEx executive vice president and CIO Glen Salow has claimed that there's potential for "hundreds of millions of dollars" in savings from implementing the utility model.