Data Center Strategies: What does the Cloud Need? Standards for Infrastructure as a Service

Cloud computing has both promise and issues. Certainly there are advantages to using externally hosted IT services...everything from more enhanced IT service delivery to increased IT agility. But there are also serious issues such as risk management, vendor relationship management, SLAs, QoS, etc., etc, etc.

But before we get ahead of ourselves, we need to ask "What is technically feasible in the cloud?". There are some real non-starters for some parts of the cloud that we need to think about. Using this diagram as a tiered architectural model for the cloud, let's talk about some of the issues at the System Infrastructure as a Service layer.

First question is: How do we migrate between clouds? If we're talking System Infrastructure as a Service, then what happens when I try to migrate a virtual machine (VM) between my internal cloud running ESX (say I'm running VDC-OS) and a cloud provider who is running XenServer (running Citrix C3)? Are my cloud vendor choices limited to those vendors that match my internal cloud infrastructure? Well, while its probably a good idea, there are published standards out there that might help. Open Virtualization Format (OVF) is a meta-data format used to describe VMs in standard terms. While the format of the VM is different, the meta-data in OVF can be used to facilitate VM conversion from one format to other, thereby enabling interoperability. While converting VMs is something that makes me a little wary now, I think we'll definitely get used to the idea as the cloud progresses.

Another biggie is application state and connection management. When I move a workload from one location to another, the application has made some assumptions about where external resources are and how to get to them. The IP address the application or OS use to resolve DNS names probably isn't valid now that the VM has moved to a completely different location. That's where Locator ID Separation Protocol (LISP -- another overloaded acronym) steps in. The idea with LISP is to add fields to the IP header so that packets can be redirected to the correct location. The "ID" and and "locator" are separated so that the packet with the "ID" can be sent to the "locator" for address resolution. The "locator" can change the final address dynamically, allowing the source application or OS to change locations as long as they can reach the "locator".

There are lots of other issues including storage and data management (huge issue), performance, and several others. I discuss some of these issues, and define the cloud, in a cloud presentation I made at the Cloud Summit Conference recent, hosted by BrightTalk. Check it out: