我想了解减轻基于云的系统的供应商锁定风险的最佳方法是什么。
例如，我想将多个不同的系统部署到 Amazon EC2 或 Windows Azure，但我希望在必要时最大限度地降低将这些系统迁移到替代云供应商的成本。
至少，我似乎越依赖供应商特定的解决方案（例如 Amazon Queue Service），我本质上就越被锁定（至少我是这么认为），但我想更好地理解这种风险以及任何超出它的内容。
是否有我可以使用的架构策略来缓解这种情况（例如，依赖 MapReduce，因为我的脚本将可移植到另一个 MapReduce 云环境）？是否有比其他操作系统或堆栈更好的操作系统或堆栈（Linux、LAMP？）。使用 JClouds 有帮助吗？
理想情况下，我希望设计可以部署在 EC2 上的虚拟系统，然后可以轻松迁移到 Azure 或 App Engine（反之亦然）。
我通常使用 Java 编写，但正在考虑选择性地使用 Scala 和 Python（或 Jython），并且通常仍尝试保持基于 JVM 的方式。我倾向于进行大量并行处理，并依赖 SQL 和非 SQL（但不一定是 NoSQL）存储和数据操作技术。
提前致谢。希望我在这里不会太不切实际。
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.
发布评论
评论（4）
在我看来，您描述的问题的唯一架构模式是： 抽象
确保坚持使用不同供应商提供的资源，例如存储、队列等。为每个供应商创建抽象层。
希望这有帮助。考虑到云提供商的服务存在差异，我认为这不是一个超级简单的任务
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
我同意 IgoreK 的观点 - 如果你在代码中执行此操作，则需要大量抽象，仅此而已。
另一种选择是采用 IaaS 云方法 - 仅基于虚拟机角色设计应用程序。大多数云提供商提供某种形式的虚拟机角色 - Amazon、Azure、Rackspace 等。迁移意味着代码更改要少得多，但您需要更多的管理。
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.
Microsoft 的客户咨询团队拥有出色的 有关如何执行此操作的示例（我想我从这里下载了该项目）。其中包含大量代码，以及一些非常好的抽象，可以使事物变得“免费”。显然，与任何抽象一样，您还会引入一个新的复杂层，因此在应用它之前请确保您真正了解了所有这些层。
在大多数情况下，少即是多。即使锁定不是您想要的，但如果需要的话，“修复”可能并不难。但问问自己，现在满足该需求是否重要，还是应该完成项目，然后再进行重构。
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.
老实说，你的问题是基于一个错误的前提。您希望避免锁定，而不是试图充分利用您选择使用的平台。
解决这个问题的更好方法不是尝试让您的基础设施可热插拔（例如，避免供应商锁定），而是实际做出决定您想要使用的 IaaS 提供商并尽可能地利用它。
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.