Cloud portability might become a topic of conversation more often as greater numbers begin to adopt their chosen cloud platform. How do we not repeat the age old “Single Vendor Lock In” in our excited rush? If the cloud provider is an Infrastructure play (i.e. Virtual Machines a la EC2 or GoGrid) then the deployment process becomes critical. Is it flexible enough to take the app and target a different virtual machine image? If you already have multiple environments to deploy to (development, test, system test,pre-production, production etc.) then hopefully you are well set up to target yet another one…
What if you chose a cloud Platform player – e.g. Azure? Can you take such an app and deploy it to Amazon SQS, CloudDB instead? Probably not the sort of thing a deployment process could handle. Virtualisation is often the answer here in the way that Java helped to make apps move between hardware and OS variants.
Fancy some new coffee flavour to virtualise Cloud Platform services? Models that execute in a Common Cloud Runtime (to make a Microsoft Oslo reference)? I am not sure I see that happening.
Seriously though: in the early days where pricing models are still forming and changing how are you planning to keep your options open? Maybe the proposition of the Platform clouds will be so compelling you will take the risk of SVLI over the on-premise/infrastructure clouds and see how the next few years play out. An alternative is to use polymorphism, lots of abstractions and layers making the SQL Data Services Platform interchangeable with CloudDB or use ORMs to try and make that magic happen for you (perhaps even a new ODBC driver for SDS / CloudDB)!. This is not going to be so simple if the capabilities of the cloud databases are significantly different.
If you are a product vendor that wants to be cloud-neutral you might have a lot to think about right now. Perhaps you’ll just target the Infrastructure clouds which should make the product friendly to those using on-premise as well. Perhaps the Platform clouds mean you will instead move to SaaS and not make it your customer’s concern at all – making it yours instead.
if you are a custom solutions developer don’t forget to factor in the expected lifetime in to your planning as this may mitigate the need to worry about SVLI as portability may be moot.
If the pricing models vary enough over the coming years, architectures may struggle to adapt. Architectures often feature patterns that favour the prevalent economics (mainframe vs distributed for example). If the pricing models of cloud platforms are relatively volatile (network usage, server calls, storage space, compute hours, memory demands etc.) it may prove tricky to be the best solution over the lifetime of the solution.