Architectural strategies to minimize cloud lock-in risk?

Question

I would like to understand what is the best way to mitigate risk of vendor lock-in for cloud-based systems.

For example, I'd like to deploy a multitude of different systems to, say, Amazon EC2 or Windows Azure, but I'd like to minimize the cost of migrating those systems to an alternative cloud vendor if/when necessary.

At the very least, it seems like the more I rely on vendor-specific solutions (like Amazon Queue Service), the more I'm inherently locked in (at least I think so), but I'd like to understand this risk better and any beyond it.

Are there architectural strategies I can use to mitigate this (e.g., rely on map reduce, since my scripts will be portable to another map reduce cloud env)? Are there O/S or stacks that are better than others (Linux, LAMP?). Is using JClouds helpful?

Ideally, I'd like to design virtual systems that can be deployed on EC2, for example, but then easily migrated to Azure or App Engine (or vice versa).

I generally write in Java, but am considering selective use of Scala and Python (or Jython) and am generally still trying to stay JVM-based. I tend to do a lot of parallel processing, and rely on both SQL and non-SQL (but not necessary NoSQL) storage and data manipulation technologies.

Thanks in advance. Hope I'm not being too unrealistic here.

Answer 1

In my opinion, the only architectural pattern to the problem you describe is: abstraction

Make sure to stick to using resources that are offered across various vendors,like storage, queue, etc. Create abstraction layers for each of them.

Hope this helps. I don't think its a super simple task to do, given the variability of the services across cloud providers