最小化云锁定风险的架构策略？答案

【问题标题】：Architectural strategies to minimize cloud lock-in risk?最小化云锁定风险的架构策略？
【发布时间】：2011-06-05 16:24:56
【问题描述】：

我想了解在基于云的系统中降低供应商锁定风险的最佳方法是什么。

例如，我想将大量不同的系统部署到 Amazon EC2 或 Windows Azure 等，但我想在必要时尽量减少将这些系统迁移到替代云供应商的成本。

至少，我似乎越依赖供应商特定的解决方案（如 Amazon Queue Service），我就越天生就被锁定（至少我是这么认为的），但我想了解这种风险会更好，而且不会超出它。

是否有我可以使用的架构策略来缓解这种情况（例如，依赖 map reduce，因为我的脚本可以移植到另一个 map reduce 云环境中）？是否有比其他更好的 O/S 或堆栈（Linux、LAMP？）。使用 JClouds 有用吗？

理想情况下，我想设计可以部署在 EC2 上的虚拟系统，例如，然后可以轻松迁移到 Azure 或 App Engine（反之亦然）。

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

提前致谢。希望我在这里不会太不切实际。

【问题讨论】：

【解决方案1】：

在我看来，您描述的问题的唯一架构模式是：抽象

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

希望这会有所帮助。考虑到云提供商之间服务的可变性，我认为这不是一项超级简单的任务

【讨论】：

【解决方案2】：

我同意 IgoreK - 如果您在代码中执行此操作，将需要大量抽象，仅此而已。

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

【讨论】：

如果您完全在 VM 上手动构建工作负载，那么您将错过 PaaS 必须提供的好处。恕我直言，仅仅为了避免锁定而切换到 IaaS 可能不是正确的方法。为手头的问题抽象 PaaS 解决方案元素是我解释@Igorek 响应的方式。例如，考虑使用队列提供者，即抽象数据从队列中写入和读取的方式。这意味着您需要为每个云平台编写提供程序，但该解决方案在架构上是免疫的。

【解决方案3】：

老实说，您的问题是基于一个错误的前提。您希望避免锁定，而不是尝试充分利用您选择使用的平台。

解决该问题的更好方法不是尝试让您的基础架构可热插拔（例如，避免供应商锁定），而是真正对您的 IaaS 提供商做出决定希望尽可能地使用和利用它。

【讨论】：

【解决方案4】：

Microsoft 的客户咨询团队有一个出色的sample on how to do that（我想我是从这里下载的项目）。里面有很多代码，还有一些非常好的抽象来让事情“免费”。显然，与任何抽象一样，您还引入了一个新的复杂层，因此在应用它之前确保您真正了解了所有这些。

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

【讨论】：