将云锁定风险降至最低的架构策略？

Question

我想知道降低云系统供应商锁定风险的最佳方法是什么。

例如，我希望将大量不同的系统部署到亚马逊EC2或Windows Azure，但如果需要，我希望将这些系统迁移到替代云供应商的成本降至最低。

至少，似乎我越依赖于特定于供应商的解决方案(如Amazon Queue Service)，我就越被锁定(至少我是这样认为的)，但我想更好地了解这种风险以及任何超越它的风险。

有没有架构策略可以用来缓解这个问题(例如，依靠map reduce，因为我的脚本可以移植到另一个map reduce云环境中)？是否有比其他操作系统更好的操作系统或堆栈(Linux、LAMP?)。使用JClouds有用吗？

理想情况下，我希望设计的虚拟系统可以部署在EC2上，但是可以很容易地迁移到Azure或App Engine (反之亦然)。

我通常用Java编写，但正在考虑选择性地使用Scala和Python (或Jython)，并且通常仍在尝试保持基于JVM。我倾向于进行大量的并行处理，并且同时依赖SQL和非SQL(但不是必需的NoSQL)存储和数据操纵技术。

提前谢谢。希望我在这里不是太不现实。

Answer 1

在我看来，您所描述的问题的唯一体系结构模式是:抽象

确保坚持使用不同供应商提供的资源，如存储、队列等。为每个供应商创建抽象层。

希望这能有所帮助。我不认为这是一项非常简单的任务，因为云提供商之间的服务是多变的

Answer 2

我同意IgoreK的观点--如果你用代码来做这件事，它将需要大量的抽象，仅此而已。

另一种选择是采用IaaS云方法-仅基于虚拟机角色设计应用程序。大多数云提供商提供某种形式的虚拟机角色- Amazon、Azure、Rackspace等。迁移意味着更少的代码更改，但对您来说更多的是管理。

Answer 3

微软的客户顾问团队有一个很棒的sample on how to do that (我想我是从这里下载的)。其中有大量的代码，还有一些非常好的抽象来让事情变得“免费”。显然，与任何抽象一样，您还引入了一个新的复杂性层，因此在应用它之前，请确保您真正地完成了所有的复杂性。

在大多数情况下，少即是多。即使锁定不是您想要的东西，如果需要的话，“修复”它可能也不是那么难。但是问问你自己，现在满足这个需求是否很重要，或者你应该完成项目，然后再重构。