9

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

例如，我想将大量不同的系统部署到 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）存储和数据操作技术。

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

4

4 回答 4

5

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

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

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

于 2011-01-08T07:08:28.730 回答
1

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

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

于 2011-01-09T00:12:58.030 回答
0

微软的客户咨询团队有一个很好的例子来说明如何做到这一点（我想我从这里下载了这个项目）。里面有很多代码，还有一些非常好的抽象来让事情“免费”。显然，与任何抽象一样，您还引入了一个新的复杂层，因此在应用它之前确保您真正了解它。

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

于 2011-07-03T18:11:42.160 回答
-2

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

解决该问题的更好方法不是尝试让您的基础架构可热插拔（例如，避免供应商锁定），而是实际决定您想要使用的 IaaS 提供商并尽可能地利用它可能可以。

于 2011-01-09T20:44:32.233 回答