The term Escape Velocity is the speed needed to “break free” from a gravitational field without further propulsion according to Wikipedia.org. Data Gravity as explained in THIS previous post is what attracts and builds more Data, Applications, and Services on Clouds. Data Gravity also is what creates a high level of Escape Velocity to move to another Cloud.
Some background on why this post is timely:
A few days ago Amazon announced a new AWS service for importing VMware disk images (VMDKs) into EC2. VMware already offered a method for converting EC2 instances through their Converter tool into Workstation VMs and with a 2nd pass conversion into ESX VMs. While all of this sounds wonderful and it does have value, it brings to light an entirely different issue. Only Stateful / Fully encapsulated applications can be moved around in this way.
Examples of sources of Cloud Gravity (App, Service, and Data Gravity Combined) on your specific Application.
If someone selects a Cloud provider and writes an application leveraging anything more than a handful of VMs, Data Gravity will make it virtually impossible to move to a new/different Cloud provider. Don’t believe it?
See the Diagrams Below:
Here is a diagram of an app that has a Low Escape Velocity because of Lower Cloud Gravity:
Below is a diagram of an app that has a High Escape Velocity because of High Cloud Gravity:
Some potential dependencies include:
Database with a specific API
Web Worker which serves as a web interface and uses internal Authentication (Your user logins are here!)
Application code that uses the Database and Web Workers specific APIs and/or depends on Low Latency and High Throughput access to them.
Here are a few additional things to think about:
– The longer (more time) an Application stays in a specific Cloud the more difficult it is to move. Why? Data Gravity increases due to more Mass (data being stored). Imagine accumulating 100’s of GBs of Data, how easy will it be to shuffle/transfer that much data around?
– The more provider APIs and Services that you depend on the harder it is to move. Why? Because there are only two paths that can be taken in a move. The first is to find another provider that has the exact same set of APIs and Services (this will limit your choices). The second is to change or rewrite your application to take advantage of the new Cloud provider’s APIs and/or Services.
– Different providers have different charges for the consumption of the same resources. Your current provider gives free usage of queues for applications. The provider you are looking to go to charges after the first X number of messages on the queue. Now what do you do? You will either pay more when you move, rewrite your application to fit the new provider’s model, or pick another provider that has free queue usage.
– Different QoS guarantees from Cloud provider to Cloud provider. Some Cloud providers offer SLAs with reimbursements for outages, others only offer best effort. Some providers offer tiered Services, others only offer a single tier. What happens if you want to move and you can’t get the minimum level of QoS that you need?
This is NOT an attempt to dissuade anyone from using Public Clouds (they are incredibly valuable and powerful), but I would like more people to go in eyes wide open.
Data Gravitas 
We’re all used to having to make decisions about platform support — fortunes were made and lost on the decision to write apps for Windows vs writing them for DOS. And we all know that the more features of a platform an app takes advantage of, the harder it is to port — even between close cousins like Linux distros or GUIs.
We’ve brought this lesson over to PaaS. We intuitively understand that making the choice to use AppEngine or VMforce or Azure has a lock-in factor.
But I think you’re right that collectively we’re not used to thinking of aspects of system architecture as platform features, even for an IaaS stack. It’ll be interesting to see people start to drill down to some more rigorous comparisons of what it takes to move between various species of clouds, and what you give up by being lowest common denominator.
You need to start thinking about your application as a legacy application as soon as you wrote it. Does not matter if it is on a cloud or not. Also given how easy it is for amazon to kick their clients off the cloud (see wikileaks case) you must have a contingency plan.
My intepretation is you are advocating (1) loose coupling (2) abstraction. If so, I agree, these are very important architecture philosophies required for integrating the Cloud.