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.

Ugaritic

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

Fluorometer

Answer 2

I agree with IgoreK - if you're doing this in code, it'll take a lot of abstraction, that's about it.

Another option is to take an IaaS cloud approach - design your application based on Virtual machine roles only. Most Cloud providers offer some form of Virtual machine role - Amazon, Azure, Rackspace etc. Migration then means far less code changes, but a bit more admin on your side.

Firedrake

If you handbuild the workload entirely on VM then you are missing out the benefits that PaaS has to offer. IMHO, switching to IaaS merely to avoid lock-in might not be the right way. Abstraction of PaaS solution elements for the problem in hand is how I interpret @Fluorometer response. e.g consider using providers for queues i.e. abstract the way data is written and read from queue. This would mean you need to write providers for each cloud platform but the solution would be architecturally immune. – Ahouh

Answer 3

Microsoft's Customer Advisory Team has an excellent sample on how to do that (I think I downloaded the project from here). There's a whole lot of code in it, and some really good abstractions to make things "free". Obviously, as with any abstraction, you also introduce a new layer of complexity so make sure you really all of it before applying it.

In most cases, less is more. And even though a lock-in is not something you want, it's probably not that hard to "fix" if the need arises. But ask yourself if it's important for that need to be satisfied now, or should you finish the project, and refactor later.

Hundred

Answer 4

Honestly, your question is based on a bit of a false premise. You're looking to avoid lock-in rather than trying to take full advantage of the platform you've chosen to use.

The better way of approaching the issue is not to try to have your infrastructure be hot-swappable (e.g., avoid vendor lock-in), but to actually make a decision about the IaaS provider you want to use and leverage it as best as you possibly can.

Negrito