Guest View: Reality check on cloud portability

By William Vambenepe

June 1, 2009 —

Many aspects often get mixed in the discussion around "standards" and "interoperability" for cloud computing.

Let’s start with one source of confusion. The "interoperability" concern is applied to both cloud infrastructure services (in which case "interoperability" means a way to provide application portability between cloud providers) and to cloud-hosted applications themselves.

Application-level interoperability ("look, my GAE-hosted app successfully sent an HTTP request to an Azure-hosted app") is not very new or exciting and is often used as an interoperability smokescreen by cloud providers who don't want to talk about cloud infrastructure interoperability. Yet, it is cloud infrastructure interoperability (in other words, application portability) that is the more interesting discussion—in part because it’s far from being a given. Consider the current diversity of offerings such as EC2, Google App Engine, Force.com, GoGrid, Azure, etc.

Another reason why it’s interesting is because it affects the dreaded vendor lock-in.

The other source of confusion in the cloud discussion at large is what we are calling “cloud.” Discussions of cloud taxonomies or even ontologies were all over the blogosphere a couple of months ago, but not much came out of them. We're still limited to the base segmentation between IaaS (infrastructure as a service), PaaS (platform as a service) and SaaS (software as a service). Let's at least be specific about which of the three we are talking about.

For this Guest View at least, "cloud portability" represents interoperability between cloud services (that is, application portability) in the IaaS and PaaS scenarios. We'll leave the SaaS case aside, even though the border between PaaS and SaaS can be porous if your SaaS application is heavily customizable (at what point does config become code?).

In lists of "things that need to happen before the enterprise moves to the cloud" and other CIO mind-reading exercises, we often see cloud portability as one of the main requirements for adoption, usually second only to some security concerns. Obviously no one will ever willingly subject him or herself to vendor lock-in again, right? No way will they deploy an application on Google App Engine unless they can easily move it to Azure, or from Amazon to GoGrid.

There are two reasons to be very suspicious of this claim: The first one is historical, the second is technical.

Historically, vendor lock-in is as old as commerce. It's not like CIOs woke up in the middle of this decade and suddenly realized its downsides. They've been allowing it for a long time, not out of stupidity, but as an understood compromise. You list standards in your RFP, but when time comes to deploy, you understand the tradeoff between the standard and the proprietary optimization, and you make a conscious decision to create some vendor lock-in by using the proprietary extension. The same logic will always apply. Vendor lock-in is only bad if it costs more than it brings in.

I am more interested in the technical reason to be skeptical of the claim that cloud portability is a gating factor for cloud adoption.

Simply put, cloud portability (especially through open standards, which is the preferred kind) is a huge endeavor, one that dwarfs any previous portability achievement. In practical terms, it is unrealistic to expect it for real-life applications considered in their entirety: the application runtime, the data, the application delivery services, the management infrastructure, the security, the metering/billing, etc.

I am sure there will be plenty of nice demos of prototype applications moving from one provider to another (either as applications or as virtual machines). Clap, clap, clap… until you realize that they left behind their monitoring capabilities. That their configuration rules don't validate anything anymore. That your printer ran out of red ink when printing the latest compliance report. That the SSL encryption/decryption (which used to be through an accelerator) is killing your servers. That the connection to your in-house application is broken. And so on.

I am not saying none of those can be handled in a standard and portable way. I am saying that they will not all be at the same time. For this too we can look at what history has to teach us.

SQL is a good comparison. Java EE is another one. They provide a good reality check. They too are standards that are supposed to prevent vendor lock-in. How many applications do you know are certified and supported on any SQL database, any UNIX operating system and any Java EE app server? And yet, standardizing queries on relational data (SQL) and standardizing an enterprise-class runtime environment for one programming language (Java EE) are pretty constrained scopes in the grand scheme of things, at least compared to all the aspects that you need to standardize to provide real cloud portability (security, monitoring, provisioning, configuration, language runtime and/or OS, data storage/retrieval, network configuration, delivery services, integration with local apps, metering/billing, etc.).

And we're supposed to put together a nice bundle of standards that will guarantee drag-and-drop portability across all these concerns? And application vendors are supposed to test and support deployments in any cloud environment that claims to follow these standards? In how many lifetimes?

These are just the technical aspects. You'd also have to deal with the human and process-centric aspects, chiefly support and administration. As far as VMware’s Open Virtualization Format is concerned (to pick just one candidate standard for a piece of the cloud portability stack), it is miles ahead of any standardization of the IT management processes involved.

This doesn't mean that cloud infrastructure standards are not useful. They make application portability possible, if not free. They make for much improved productivity through generic tools and reusable developer knowledge. We still need all this. And worst case, they'll just turn out to be a detour on the road toward in-house data center automation.

Here is the best that can realistically happen in the cloud application portability area for at least 10 years:

A set of partial standards for small parts of the cloud-computing domain (see list above), many of which already exist.

A set of RightScale-like tools that do a lot of the grunt work of mapping/hiding/transforming between providers, with various degrees of success.

The need for application providers to certify their applications on cloud providers one by one anyway, and to provide cloning/migration as a feature of the application rather than an infrastructure-level task.

Either the scenario above is acceptable (the benefits of using the cloud services are worth the less-than-zero switching cost between cloud providers) or it is not. If it is, then let's admit it upfront and be realistic in our approach to cloud standards. If it isn't acceptable, then cloud computing might go back to being, for most people at least, the kind that has been with us since before it was called "cloud": SaaS and just SaaS.

William Vambenepe is an architect at Oracle working on the Enterprise Manager product. He blogs at stage.vambenepe.com.

Related Search Term(s): cloud computing

Share this link: http://www.sdtimes.com/link/33502

Electric Cloud floats into Amazon's EC2 Electric Cloud's ElectricAccelerator and ElectricCommander ALM tools now work with Amazon's Elastic Compute Cloud.

Platform Computing brings HPC to cloud management A newly released beta of Platform ISF aggregates resources from virtual machines, clusters and grids.

Short Takes: October 15, 2008 Our editors take a look at how Oracle's OpenWorld is becoming more eco-conscious, why the iPhone is better than the BlackBerry, the convenience of watching TV shows online and tips from Secure Computing on securing your infrastructure.

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST