多云弊大于利，开源或是唯一明智的应对策略

编者按：在企业内部，一些员工为特定项目使用特定的云计算供应商提供的服务，而另外一些员工为另一个项目选择不同的云计算供应商。企业之外，越来越多的云技术提供商业开始大肆宣扬多云、混合云的优势，但是对于采用多云技术的企业而言，这往往意味着企业管理成本上升、控制访问或应用程序、数据保护都将变得更为困难。 

近日，某海外科技媒体刊发了 AWS 工程师对于多云策略的反对观点，并且提出企业/云厂商更加积极的拥抱开源，这可能是有效解决多云弊端唯一明智应对策略的看法。InfoQ 特别整理编译了该篇文章，供 IT 业界人士阅读。

大多数组织使用多个云，但是对于大多数公司而言，这与某些宏伟的战略无关。相反，正是由于缺乏战略，才导致了其组织内部运行了多个云。或者按照 Gartner 的说法，是公司为不同的工作负载选择不同的云，而导致的企业最终不得不被迫采购多云技术。

无论如何，多云的策略往往意味着更多额外的成本和复杂性，尽管其往往被吹捧为灵丹妙药，但事实是弊大于利。

多云只是理论上很棒

软件即服务（SaaS）是一种许可模型，在这一模型之下，企业可基于订阅向客户提供对应用程序的访问能力，而由第三方的云厂商服务机构提供控制访问并负责安全性，运维等服务。

在那里，一切听起来都非常完美，我们的业务完全建立在一个云端环境中，随着业务的发展，当我们决定将在 Cloud A 上的业务及相关内容转移到另外一家云提供商（Cloud B）上的时候，我们只需轻轻的按一下 Cloud A 的“关闭”开关，然后再轻按一下 Cloud B 上的“打开”开关，一切就可以以一种极其简单的方式完成切换。

然而，结果并不是这样的。事实证明，开发人员之所以决定将业务迁移到 Cloud B 上，而不是在 Cloud A 上构建业务，是因为 Cloud B 上拥有更多功能丰富的服务，这些功能在原来的 Cloud A 上并不具备，没有他们需要的东西。

随着时间的流逝，即使 Cloud A 填补了一些功能的空白，但是由于相似的功能在不同云厂商之间也会往往以不同的方式实现部署，曾经迁移出去的业务往往已经再也无法迁移回来，于是只能基于多云的模式开展业务。

事实证明，每个云都提供高度多样化的服务。即使是精通 Azure 的开发人员，也无法在 Google Cloud 或 AWS 上高效地工作。供应商正在通过出售多云扩大公司业绩，但客户往往会逐渐被沉重、低效的多云管理和高昂的维护费用所累。

建立可在任何云提供商或您自己的数据中心内无缝运行的工作负载的想法非常令人信服，但是，这与向开发人员说“只要编写没有错误的代码”一样，比看起来要难得多。因为，每个云都是不同的，具有不同的优缺点。

如果您想利用 Google Cloud 上出色的数据库选项，那么您将无法轻松地将该工作负载移植到任何其他云上。这不是因为云供应商在用邪恶的设计来锁定您，而是因为它们各自都在尝试构建客户想要使用的有用服务。

同样的情况是，无论您在怎样的云上提供服务，都难以完全将其关联的数据迁移到其他云上。

开源或许是唯一明智的应对之策

我不确定多云管理对于大多数工作负载是否有意义，但为了有效的解决多云带来的负面影响，开源或许是有效解决相关问题唯一明智的应对策略。

如果一家公司希望最大程度地提高自由度/工作负载的可移植性，则可以使用社区驱动的开源项目（例如 PostgreSQL 或 Kubernetes）来构建。这并不能解决所有问题，但是对于某些关键领域，它将是可行的。 

由于 PostgreSQL 或 Kubernetes 这一类开源项目的代码往往都被 Azure、AWS、Google cloud 等云厂商做了集成，而且企业可以免费学习、使用集成到自己的业务当中。于是，企业既可以选择在其自有的服务器上用这些开源技术管理自己的业务，同样也可以在任何云上对这些项目进行自我管理。以保证其工作负载的可移植性。

事实上，多云将与我们长期同在，企业也会持续的购买相关的多云服务。这不是因为某些宏伟的公司战略考虑，而是因为开发人员都倾向于选择适合自己的技术方案。考虑到开发人员更倾向于喜欢开源，因此，使用更多的开源技术，可能是唯一真正明智的多云策略。

作者披露：本人为 AWS 工作，但反多云是我的个人观点，这一观点在我进入 AWS 之前便已持有。