« Attention Span 2009.04.26 | Main | The Cloud's Kicking Mike D's Butt »

InterCloud Portability Reality Check

I noted the SD Times piece yesterday by David Worthington, and had something of a sinking feeling. Here was AMZN, HP, IBM, MSFT and CRM singing the cloudy version of the old Burger King spot - "Have it your way." ... "We are open and continue to be. Customer choice is our philosophy." Mmmm.   

So, with a hat tip to James Urquhart for pointing out this reality check, I want to thank William Vambenepe. What I appreciate about the discussion in this post is his willingness to distinguish what "portability" might mean when operating at the various levels of cloud service -- application, platform or infrastructure.

William is legitimately skeptical about the likelihood of "application portability across IaaS providers", though I don't think I'd buy his pessimistic prediction of 10 years to achieve it. There is certainly a challenge for workload mobility across "interoperable" IaaS providers. I'll be a bit more positive about the possibilities. I foresee a much quicker uptake on the requirements he sets out by the introduction of a new set of players or, if not new players, significantly new services offered. I think of them as the set of Core Service providers for the InterCloud.

  • standards for key parts of the Cloud computing domain that Vambenepe lists (security, monitoring, provisioning, configuration, language runtime and/or OS, data storage/retrieval, network configuration, integration with local apps, metering/billing)
  • the existence of the requisite set of third-party services to deliver the aforementioned services in a uniform, authoritative and trusted manner
  • the availability of "RightScale-like tools" or the OA&M offerings of the Core Services providers to supply a lot of the heavy lifting required for discovering, mapping, hiding, transforming. (No... I didn't write this to introduce yet another acronym ... Cloud Management as a Service is too unwieldy.)
  • certification of application platforms that support workload migration across major IaaS providers

I'm particularly taken with the notion of an industry segment made up of InterCloud Core Service providers. (Ask anyone who's been unfortunate enough to have me bend their ear for the past couple of months. It's definitely been on my list of speaking points.) I plan to put more emphasis on their identification and definition in posts over the course of the next few weeks.

Reality check on Cloud portability


Because the reality is that, Manifesto or no Manifesto, you are not going to get application portability across IaaS-type Cloud providers. At least for production applications. Sorry. As a consolation prize, you may get some runtime portability such that we’ll be shown nice demos of prototype apps moving from one provider to another (either as applications or as virtual machines). Clap clap until you realize that they left behind their monitoring capabilities, or that their configuration rules don’t validate anything anymore. And that your printer ran out of red ink when printing the latest compliance report. Oops


Standards are always supposed to prevent vendor lock-in. And there is a need for some of that, of course. But look at the track records. How many applications do you know that are certified and supported on any SQL database, any Unix operating system and any J2EE app server? And yet, standardizing queries on relational data and standardizing an enterprise-class runtime environment for one programming language 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, 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 accross all these concerns? In how many lifetimes?

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.