厂商依赖是云计算采纳的障碍？

Tim Bray上周写了一篇关于云计算采纳的文章。他觉得存在两大主要问题：

• 我们还没有找到最佳的云平台（cloud platforms）架构方案。是采取Amazon的EC2/S3“裸虚拟白盒（Naked virtual whitebox）”模型？还是采取像Google App Engine那样平台即服务（Platform-as-a-service）的风格？我们尚不知晓。
• 如果云平台要受到大家欢迎的话，那么它必须做到绝对不能出现厂商依赖的情况。

Tim最后说道：

在21世纪的今天仍然步桌面套件和私有SQL的后尘、重演厂商依赖的悲剧，我们“脑残”到这个地步了吗？你知道，那等于把IT预算控制权交给平台厂商了？

Dare Obasanjo不明白能够避免厂商依赖将意味着什么：

与Web开发平台的切换相比，从一个应用切换到另一个应用是一个类似且更容易的问题。

他认为，对于基于“云”的办公套件：

由于有 ODF和 OOXML这些标准，因此应该很容易对业务文档进行迁移。

但是他也敦促大家考虑以下问题：

有没有自动化批量执行导入导出的办法？

是不是大家只能手工进行在线文档与标准格式间的导出/导入？

若数据迁移导致指向公司数据的链接和引用失效，会有什么影响？

你们公司迁移数据需要多大的代价（包括公司因切换服务而停工，以及IT部门迁移所有数据的实际开销）？

最后，Dare建议道：

切换寄存应用提供商是件很好办的事...尽管技术上可行，然而大部分寄存应用提供商都做不到令用户可以简单方便地彻底迁入或迁出它们的服务。

至于云计算平台，Dare解释道：

你面临着跟以上情形同样的问题，以及一些额外的问题。云计算平台关键的缺点是，这些服务背后缺乏标准化的APIs与平台技术...要避免厂商依赖，需要各 个提供商实现同一组底层APIs才行。否则，云计算平台之间的迁移就会像把Ruby on Rails+MySQL切换为Django+PostgreSQL这么麻烦（等于要完全重写代码）。

Google的Dewitt Clinton在评论Tim Bray的文章时解释道：

对App Engine来说，人们随时可以在其它提供商上运行开源的userland stack（它暴露有API），而且有很多开源的bigtable实现可供你选择。尽管如此，批量导出数据仍需手工完成，不过 目前这是切实可行的，而且我们正在努力简化这个步骤。

Dewitt还说，Dare所说的已经在发生了：

但Amazon或Google除了采用正确的许可证以及尽可能编写更多的开源代码以外，如何促成它实现呢？显然，我们不会架设起多个备选实例。（尽管我们可以为之喝彩，就像当我们 看到在EC2和S3上实现了App Engine API时所做的一样。）

Mark Pilgrim觉得云计算还存在另一个问题：

真正令人害怕的问题不是厂商依赖，而是封禁。比方说，如果你的服务提供商突然认定你的帐户在进行可疑活动，然后禁用你的帐户，你 去向谁求助？当人们得知自己在没有明显理由的情况下被禁止访问权限、而且无法知道真正原因、别无他法只有重头来过时，通常会感到万分震惊。但愿他们有做备 份。

厂商依赖（或封禁）是采纳基于“云”的方案（SaaS、PaaS、IaaS）的主要症结吗？或者，你觉得一个厂商在提供更好的产品的同时，会不会像现实世界里的各种服务一样周到、为你解决迁移问题？

查看英文原文：Is Vendor Lock-in a Barrier to Cloud Computing Adoption?