Standards for cloud portability ideally will enable IT to port applications and data from one provider to another. There are three potential components of portability: data (for all cloud services), configuration (for most cloud services) and images (for IaaS services). Let's look at these by service type.
>> SaaS: Portability with SaaS is fairly straightforward: Either you can export data and configuration from a provider or you can't. Unfortunately, whether export capabilities actually prevent vendor lock-in isn't quite as clear. Can you export the data in a timely and reasonable fashion? Can your alternative vendor import the exported data? While the DataPortability Project promotes standards and policies around data transfers, it's in early stages. Expect to do application-specific investigative legwork.
>> IaaS: An IaaS deployment consists of data, virtual machine images and server configuration, including software installed on the image after launch. IaaS vendors, by definition, export data, so the only question is, how difficult will the process be? Exporting 500 GB from a database running on an IaaS virtual machine to another major vendor is fairly simple, but it may take the better part of a day. On the other hand, when exporting 500 GB of records from a cloud database-as-a-service (like DynamoDB), the transform and load process into another vendor's service (assuming such a service exists) is hit or miss, and it also may take much longer. There aren't any significant standards in data portability for IaaS vendors at this point.
There is, however, a fairly clear standard for image portability: Open Virtualization Format, released by the Distributed Management Task Force and created by Dell, HP, IBM, Microsoft, VMware and XenSource. Still, "really large image sizes break down the standard," warns Michael Biddick, CEO of Fusion PPT and an InformationWeek contributor. "And if you're moving among different hypervisors, you have to make some changes to the OVF files to make the images work." That said, OVF is about as mature a cloud standard as you'll find and, generally speaking, does deliver on image portability.
>> PaaS: While using PaaS can expose you to some lock-in risk because these vendors tend to rely on one IaaS provider, migrating shouldn't be difficult. In an ideal PaaS deployment, you bring your own code and data and rely on the PaaS vendor for the server configuration that you would have had to do yourself with IaaS, so switching PaaS services should be simple. How well that theory matches reality depends on your vendor. Heroku, for example, presents a fairly straightforward export path, whereas Google App Engine's data extraction process is painful in comparison. The good news is that a number of leading technology vendors, including Oracle, Rackspace and Red Hat have, through the standards body Oasis, proposed the Cloud Application Management for Platforms spec, which is designed to make porting applications among PaaS vendors much easier.
Here we're talking the ability to share cloud services across multiple environments, including a company's own data center, using a private cloud architecture or colocated, noncloud services. Some of the strongest cloud standards have sprung up around identity and access management (IAM) in particular, enabling single sign-on and eliminating the need to control access from multiple management interfaces. IAM dramatically simplifies rolling out new services. There are three main standards in cloud IAM:
>> Security Assertion Markup Language, from Oasis, allows cloud applications to leverage the authentication approaches a company is already is using.
>> System for Cross-domain Identity Management, created by Google, WebEx and Salesforce.com but now under the IETF's auspices, lets cloud applications use directory information from within the enterprise to provide information on user and group permissions within cloud applications.
>> OAuth, originally by Twitter and Google but also now under the IETF, allows cloud users to extend access to resources that they control to other cloud services. For example, you can use OAuth to give LinkedIn access to your Twitter account so that LinkedIn can tweet for you.