云越发展，锁定问题就会越严重？

就像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体系显然是最具粘性的。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!