随着AWS和微软Azure等超大型扩展商持续向其托管服务增加特定和独特的功能，“云中诞生的”工作负载现在在设计时，可能与平台是无关的，但这不意味着情况将总是这样。
2013年和2014年，我讨论过“服务的游戏”，以及如同HBO出品的史诗系列剧集《权利的游戏》已经播出多季一样，消费者云也经历了多次不同的变革。
总的来说，消费者云的革命主要与行业主要玩家——苹果、谷歌、微软和亚马逊——托管在其上的服务有关，以及它们这些服务存在的差异有关。
服务的游戏的第一篇章主要是关于移动OS平台，以及谁将存活下来。现在我们都知道谁赢得了这场战争：苹果和谷歌。
第二篇章是关于服务本身，服务必须提供什么样的云存储、aap、信息、音乐/视频/书籍内容，以及这些服务将如何继续发展。
第三篇章是关于对这些公有消费者云服务的API访问的战争。大多数情况下，谷歌和脸书仍旧是最重要的消费者云，而对这些API的访问则是不断变化的。
第四篇章是什么？答案是企业/商业云的革命。现在，我们将来谈论一下公有云超大型扩展商：亚马逊网络服务（AWS），微软Azure，谷歌云平台，以及规模稍逊一点的IBM。
到目前为止，企业云工作负载可以归纳为IaaS（基础设施即服务）、PaaS（平台即服务）、SaaS（软件即服务），或三者的混合。从出生的第一天就被设计为运行在云端的工作负载通常被称为“云中诞生的”工作负载，而传统的起源于本地数据中心之后又被迁移到云端的客户端服务器工作负载则是被迁移的云工作负载。
而如果你将两者结合，将它们分成云端和本地的，那么你所拥有的就是混合云基础架构。
在大多数情况下，企业/商业云都托管了可被视为商品或可互换的服务。计算/VM、存储和网络是基本的IaaS服务，这些服务在主要的超大型扩展商中实际上是一样的，而在主要的玩家中它们的价格则是一样的，都是一种竞次的方式。
在Docker等开源应用程序打包标准上运行的容器，以及使用Kubernetes等编排系统的容器，是下一代的计算——它们也正在被商品化。它们比VM更便宜，更容易扩展。如果你在一个公有云上有一个基于docker的应用程序，那么将其移植到具有类似容器托管服务的另一个公有云是相当简单的。
超大型扩展商可以尝试在性能和其他一些方面与其他供应商区分开来，但在基本层面上，IaaS就是IaaS，容器就是容器，无论你是在AWS、Azure还是在谷歌云上运行它。
SaaS和PaaS实际上是商业云的区别所在。对于像微软这样的公司来说，它的SaaS，比如Office 365、PowerBI、Dynamics、SharePoint、Teams和Skype For Business，是它区别于行业其他公司的地方。这些应用程序平台已经在本地拥有相当大的市场份额，因此对它们来说，将客户从其遗留的数字中心转移到基于云的这些托管版本即SaaS则是自然不过的了。
这些工作负载已经非常具有粘性了，因为它们被绑定到了Microsoft的Active Directory身份验证机制中，该机制是基于Microsoft的环境的基础技术。这些客户已经被锁定了，但是他们并不打算离开这些应用程序平台，因为没有太多好的替代方案。
有了平台即服务，你就拥有了各种已构建完成的应用程序服务，例如托管的数据库和机器学习系统，它们都是基于事物进行计费的。当与基于容器的PaaS结合时，这些系统就能够让企业客户构建高度可扩展的系统，否则在IaaS中实现这些系统的成本将非常高，并且可以按需提供。
到目前为止，很多这样的系统都是在开源平台上构建的，如Hadoop或MongoDB。但是现在超大规模的云提供商也开始构建他们自己的后端高度可扩展服务了，这些服务与开源服务是兼容的，但与其开源竞争对手的则并不相同。
一个这样的例子是DocumentDB，这是一个托管的数据库服务，它与MongoDB是API兼容的，但并没有使用任何实际的MongoDB代码。Amazon于本周才发布了MongoDB代码。
目前，你可以在AWS中构建应用程序，方法是使用IaaS和基于容器的系统，并将其后端到DocumentDB，然后再将它们移回本地，甚至是另一个与之竞争的超大规模的云，如微软Azure或谷歌云平台。但情况可能并不是永远是这样的。
今天，许多这些托管服务都使用了与其开源竞争对手相兼容的API。因此，代码是可移植的，并不会局限于某个云提供商。
这与从一个基于SQL的数据库移植到另一个数据库的经典问题并没有完全不同，只要它们被编码为ANSI SQL规范。在这种兼容性级别上，数据库是否从甲骨文启动并不重要，然后可以将其移动到IBM DB2甚至Microsoft SQL Server。
但是，随着这些服务变得商品化，就像IaaS在计算和存储方面所做的那样，云提供商将增加他们自己的特性增强，这将不可避免地与开源对手有所不同。而且软件开发人员喜欢利用新特性，特别是如果它们能够提高性能、提高可伸扩展性，并且能够在事务或计算成本上节省成本的话。
这也是他们首先转向PaaS、集装箱化和云中的微服务的原因之一——打造真正的“云中诞生的”应用。此外，他们可以专注于运行应用程序平台和代码，而不必担心底层基础设施。IaaS实际上只是将工作负载转换到云的中间步骤，因为你仍旧需要担心操作系统堆栈的维护。
但是，正如20世纪中期我在IBM工作时经常遇到的那样，如果为了利用性能优化而将业务逻辑放入某个特定数据库平台上的存储过程和触发器中，那么最终可能就会遇到严重的兼容问题。
比如，从甲骨文迁移到IBM DB2就不那么容易了。将业务逻辑迁移出数据库可能会花费你大量的软件开发时间（和金钱），因此你可以将其从一个平台移植到另一个平台。
我记得有一个IBM银行客户在甲骨文中有800个存储过程和触发器，而如果要删除所有这些并将逻辑转移到J2EE上的中间件中，则需要花费数百万美元。尽管DB2在许可方面比甲骨文便宜，但是软件开发成本要高得多。他们最终只得坚持使用甲骨文，但是将它迁移到了不同的操作系统和硬件平台（IBM的AIX和POWER）上，以获得所需的性能。他们被锁定在了那个数据库里。
我们可以很好地看到许多超大型的云都发生了这种情况。确实，DocumentDB现在与MongoDB兼容了。但谁能说，五年后，这些API将是相同的？DocumentDB只是一个云服务。一个高度可扩展的、在云中诞生的应用程序可能被设计成利用特定于该云提供商的十几种或更多类型的云服务。所有这些都在不断发展并获得新的特性集。
比方说，Microsoft Azure的投资组合中有多少服务？我很久以前就不再计数了。当然，其中很多都使用了开源标准，但是有多少不是呢？这些开源兼容性服务将完全保持这种状态多久？随着AWS、微软、谷歌云和IBM彼此之间的竞争越来越激烈，它们很可能不会这么做。
你对基础设施的控制失去的越多，并将注意力转移到严格运行应用程序代码和必须依赖于托管平台上，该平台变得具有粘性的可能性就越大——这正是AWS和微软等超大规模提供商所希望的。他们想让你留下。他们希望你继续购买周期和交易，他们不希望你离开他们的云。像Office 365、Workday和Salesforce这样的SaaS系统显然是最具粘性的。
这与拥有内部软件平台没有什么不同，这些平台是专有的，使用的代码不容易移植到另一个平台上。不同之处在于，你并没有授权这些平台，而是租用了这些平台上的时间，这是你的组织中精打细算的人所喜欢的，因为这是一项运营费用（OPEX），而不是资本费用（CAPEX）。
因此，你当然可以设计独立的、可移植的基于云的系统。但从长期来看，这样做在经济上可能并不可行。构建完成的云服务将比你可以在IaaS VM甚至容器中托管的服务更便宜。对于PaaS，最终的权衡将是性能、特性和成本与可移植性的对比。
