Every data center provisions its workloads for a worst-case scenario. IT managers put an application on a server with extra memory, CPU, and storage to make sure the application can meet its heaviest workload of the month, quarter, or year and grow with the business. This approach is so deeply ingrained in IT that, prior to virtualization, applications typically used 15% or less of available CPU and other resources. Storage might reach 30% utilization. Energy was cheap, spinning disks were desirable, and abundant CPU cycles were always kept close at hand.

In today's economic climate, such compulsive overprovisioning and inefficiency are no longer acceptable. What if, instead, applications throughout the data center could run at closer to 90% utilization, with the workload spikes sent to cloud service providers (a process called "cloudbursting")? What if 85% of data center space and capital expenses could be recouped, with a small portion of that savings allocated for the expense of sending those bursts of computing to the public cloud?

This tantalizing possibility--enterprise IT organizations managing an internal cloud that meshes seamlessly with a public cloud, which charges on a pay-as-you-go basis--embodies the promise of the amorphous term cloud computing. Step one with virtualization has been server consolidation. The much bigger benefit will come with the ability to move workloads on and off premises. "Anyone can build a private cloud," says Rejesh Ramchandani, a senior manager of cloud computing at Sun Microsystems. "The gain comes if you can leverage the hybrid model."

As Sun CTO and cloud advocate Greg Papadopoulos suggested during Structure 09 in San Francisco on June 25, "it will be really expensive and hard to move legacy pieces over. It's a much better strategy figuring out what are the new pieces that I want to move to the cloud."

Papadopoulos was implicitly pointing out that most public cloud services run virtual machines based on an x86 architecture. Sun's Solaris has been ported to x86, but IBM's AIX and most other Unixes have not, to say nothing of the non-Unix operating systems that preceded them. But those operating systems run mostly large, proprietary databases, the stuff that's hardly ripe for the public cloud anyway.

Other Obstacles
Moving data center workloads would immediately run into two more likely obstacles: the need to use the same hypervisor in both clouds, and the need to match up server chipsets. If you think you're already paying enough for virtualization software, prepare to pay more if you ship workloads to the public cloud. Call it vendor lock-in.

VMware and other hypervisor vendors have agreed only to create a common "import format," not a neutral runtime format. To avoid the complication of reconverting from the public cloud's format to your own, you'll want to use the same hypervisor if you plan to get your workload back behind the firewall in its original configuration. (Even that wasn't possible with the initial offering of Amazon.com's Elastic Compute Cloud, or EC2. You shipped off a task, it ran, then it disappeared. You got the results, but if there were any special settings or other one-time-only information contained in the configuration and its data, they simply disappeared. Amazon's Elastic Block Storage had to be invented to give the whole workload persistence.)

Did you want the option of using open source Xen or Linux KVM in the cloud, but you use VMware in-house? Too bad. Kiss some of those cloud savings goodbye as you buy more VMware.

Virtualization's live migration feature, where a task is whipped off one physical server and dropped onto another before its users are aware of it, would appear to give you the option of moving workloads at will between your private and public clouds. VMware's VMotion and Citrix Systems' XenMotion offer this capability today; Microsoft says its Hyper-V tools will be able to do so by the end of this year.

But so far, live migration can take place only between physical servers that share exactly the same chipsets. That's because different generations of AMD and Intel chips incorporate minute changes to the x86 instruction set and sometimes within different iterations of the same product line, such as Xeon. Want to shift a spike in your workload off to the public cloud? First check that you're both running servers with exactly the same chipsets.