我想了解什么是降低基于云的系统的供应商锁定风险的最佳方法。
例如，我想将多种不同的系统部署到Amazon EC2或Windows Azure，但我希望在必要时尽量降低将这些系统迁移到其他云供应商的成本。
至少，我似乎越依赖特定于供应商的解决方案（如亚马逊队列服务），我就会越多地锁定（至少我是这么认为），但我想了解这种风险更好，任何超出它的风险。
我是否可以使用架构策略来缓解这种情况（例如，依赖map reduce，因为我的脚本可以移植到另一个map reduce cloud env）？是否有比其他更好的O / S或堆栈（Linux，LAMP？）。使用JClouds有用吗？
理想情况下，我想设计可以部署在EC2上的虚拟系统，但随后可以轻松迁移到Azure或App Engine（反之亦然）。
我通常用Java编写，但我正在考虑选择性地使用Scala和Python（或Jython），并且我通常仍然试图保持基于JVM的。我倾向于进行大量并行处理，并依赖于SQL和非SQL（但不是必需的NoSQL）存储和数据处理技术。
提前致谢。希望我在这里不是太不现实。
答案 0 :(得分：5)
在我看来，您描述的问题的唯一架构模式是：抽象
确保坚持使用各种供应商提供的资源，例如存储，队列等。为每个供应商创建抽象层。
希望这会有所帮助。考虑到跨云提供商的服务的可变性，我认为这不是一项非常简单的任务
答案 1 :(得分：1)
我同意IgoreK - 如果你在代码中这样做，它将需要大量的抽象，就是这样。
另一种选择是采用IaaS云方法 - 仅基于虚拟机角色设计应用程序。大多数云提供商都提供某种形式的虚拟机角色 - 亚马逊，Azure，Rackspace等。迁移意味着更少的代码更改，但更多的管理员在您身边。
答案 2 :(得分：0)
微软的客户咨询团队有一个很好的sample on how to do that（我想我从这里下载了这个项目）。其中有很多代码，还有一些非常好的抽象来让事情“免费”。显然，与任何抽象一样，您还会引入一个新的复杂层，因此在应用它之前请确保您真正完成所有这些操作。
在大多数情况下，少即是多。即使 lock-in 不是你想要的东西，如果需要的话，可能并不难以“修复”。但是问问自己现在是否需要满足这个需求是否很重要，或者你是否应该完成项目，然后重构。
答案 3 :(得分：-2)
老实说，你的问题是基于一个错误的前提。您希望避免锁定，而不是试图充分利用您选择使用的平台。
解决问题的更好方法不是尝试让您的基础架构可以热插拔（例如，避免供应商锁定），而是实际做出关于IaaS提供商的决定我希望尽可能地使用和利用它。