就像HBO的史诗奇幻剧《权力的游戏》(Game of Thrones)有好几季一样，消费者云计算(consumer cloud)的发展也经历了不同的阶段。

　　总结一下，这场由苹果，谷歌，微软和亚马逊等巨头发起的“服务的游戏”第一季围绕于移动操作系统平台，赢家是苹果和谷歌。

　　而第二季是关于服务本身，这些公司在云存储，应用程序，消息，音乐/视频/书籍内容方面提供了大量服务，以及不断推进这些服务的发展。

　　第三季是关于公有消费者云服务的API访问之争。从很大程度上来说，如今谷歌和Facebook仍是最重要的消费者云，而对它们中的各类API进行访问也是一个不断变化的目标。

　　第四季的内容呢?答案是企业/商业云的发展。我们在这里讨论的是公有云的超级扩张者: AWS、微软Azure、谷歌云，以及IBM云。

　　到目前为止，企业云工作负载可以分为IaaS、PaaS、SaaS或三者的混合。这类天生时就被设计成在云中运行的工作负载通常被称为“生于云”工作负载，而那些自本地数据中心的传统客户机/服务器迁移到云中的负载，则被称作迁移工作负载。

　　如果我们把这些东西结合起来，并在云和本地之间进行分割，就得到了混合云架构。

　　在大多数情况下，企业/商业云托管服务可以被视为一种商品并进行互换。计算/虚拟机、存储和网络是基本的IaaS服务，这些服务在巨头中是一样的，它们也都应用了一种逐底竞争的方式。

　　在Docker等开源应用程序打包标准上运行的容器，以及使用Kubernetes等编排系统的容器，是下一代的计算，而这也正在被商品化。它比虚拟机更便宜，也更容易扩展。如果在一个公有云上运行一个基于Docker的应用程序，那么将其移植到具有类似容器托管服务的另一个公有云上是相当简单的。

　　超大规模用户(hyperscalers)可以尝试在性能和其他一些方面对这些服务进行区分，但在基本层面上，IaaS还是IaaS，而容器还是是容器，无论它们是在AWS、Azure还是谷歌云上运行。

　　实际上，厂商商业云的区别在于SaaS和PaaS。对于像微软这样的公司来说，它的SaaS，比如Office 365、PowerBI、Dynamics、SharePoint、 Teams和Skype For Business，是它区别于行业其他公司的地方。这些应用程序平台曾在本地拥有相当大的市场份额，因此将客户转移到基于云的托管版本(SaaS)是IT从传统安装过渡到现代化访问的一项自然过程。

　　但这些工作负载非常棘手，因为它们被绑定到微软的Active Directory身份验证机制中，该机制是基于微软的环境的基础技术。由于这些客户已经被锁定，他们并不打算离开这些应用程序平台，因为没有更好的替代方案。

　　另一方面，通过PaaS，用户可以托管数据库来托管机器学习和大数据计算等系统，而这些都是基于事务计费的。当这些系统与基于容器的PaaS结合时，企业客户可以被允许构建高度可扩展的系统，否则在IaaS中实现这些系统的成本将非常高，并且可以按需供应。

　　到目前为止，很多这样的系统都是在开源平台上构建的，如Hadoop或MongoDB。但是现在我们开始看到超大规模云供应商也构建他们自己的后端高度可扩展服务，这些服务与开源服务兼容，但并不相同。

　　一个这样的例子是AWS最近发布的DocumentDB，这是一个托管的数据库服务，它可兼容MongoDB的API，但不使用任何实际的MongoDB代码。

　　目前，用户可以在AWS中构建应用程序，使用IaaS和基于容器的系统，并将后端应用程序构建到DocumentDB中，稍后也可以将它们移回本地，甚至是另一个与之竞争的超大规模云服务中，如微软Azure或谷歌云平台，但这可能不是完全不受限的。

　　今天，许多托管服务都使用与开源服务兼容的API。因此，代码是可移植的;它并不局限于云供应商。

　　这与从一个基于SQL的数据库移植到另一个数据库的经典问题并没有完全不同，只要它们被编码为ANSI SQL规范。在这种兼容性级别上，数据库是否从Oracle启动并不重要，然后可以将其移动到IBM DB2甚至微软SQL Server上。

　　但是，随着这些服务变得商品化，就像IaaS在计算和存储方面所做的那样，云供应商将增加他们自己的特性增强，这将使它们与开源对手们有所不同。软件开发人员会喜欢这些新特性，特别是它们能够提高性能与可扩展性，并且能够在事务或计算成本上节省成本。

　　这也是他们转向PaaS、容器和云中微服务的首要原因之一——打造真正的“云原生”应用。此外，他们可以专注于运行应用程序平台和代码，而不必担心底层基础设施。IaaS实际上只是将复杂转移到了云中间层，所以用户仍需担心系统堆栈的维护与操作。

　　不过，如果为了利用性能优化而将业务逻辑强行放入某个特定数据库平台上进行存储与运行，那么用户最终可能会遇到严重的兼容性问题。

　　这样想，从Oracle转移到IBM DB2就不是一件简单的事了。将业务逻辑移出数据库可能会花费用户大量的软件开发时间(和金钱)，因此它们可以选择将其从一个平台移植到另一个平台。

　　曾有一个IBM的银行业客户在Oracle中放置了800个存储过程和触发器，如果要删除所有这些并将逻辑转移到J2EE上的中间件中，则需要花费数百万美元。尽管DB2在许可方面比Oracle便宜，但是软件开发成本要高得多。最终客户还是选择了使用Oracle，但还是将其迁移到不同的操作系统和硬件平台(IBM的AIX和POWER)以获得所需的性能。不过，该客户还是被锁定在了Oracle的数据库中。

　　这样的情况也发生在更大规模的云中。当然，DocumentDB现在与MongoDB兼容了。但谁能说，五年后，这些API将是相通的呢?DocumentDB只是一个云服务，一个高度可扩展的、在云中诞生的应用程序可能被设计成仅特定于某云供应商的十几种的云服务产品。

　　比如，微软Azure的组合中有多少服务?不可胜数。当然，其中很多都使用开源标准，但是又有多少不是呢?而且，那些与开源兼容的服务将完全保持这种状态多久? 随着AWS、微软、谷歌云和IBM彼此之间的竞争越来越激烈，它们很可能会放弃目前的想法。

　　企业用户越失去对基础设施的控制，并将注意力转移到严格运行应用程序代码和必须依赖于托管平台上，该平台变得棘手的可能性就会越大，而这正是AWS和微软等超大规模供应商所希望的。他们想让客户留下。他们希望他们不断进行购买和交易。他们不希望客户离开他们的云。像Office 365、Workday和Salesforce这样的SaaS系统显然是最具粘性的。

　　其实这与拥有本地软件平台没有什么不同，这些平台是专有的，使用的代码不容易移植到另一个平台。不同之处在于，用户并没有授权这些平台，而是租用了这些平台上的空间，这是组织中精打细算的人所喜欢的，因为这是一项运营费用(OPEX)，而不是资本费用(CAPEX)。

　　因此，用户当然可以设计出基于云的系统，这些系统是相当独立且是可移植的。 但长期这样做可能在经济上不可行。 对比之下，完全的云服务将比用户在IaaS中使用虚拟机中或甚至在容器中托管的服务便宜。 而使用PaaS，权衡关键最终将取决于性能，功能以及成本与可移植性。

　　那么随着我们越来越依赖完成的云服务，云锁定是不可避免的吗?

　　责任编辑：DJ编辑