让多云变得更好：为什么它很糟糕，以及如何让它变得更好

实际上，每一项行业调查都会告诉您：大约80%到90%的企业(从中小企业到企业)都在使用多个云，其中越来越多的企业将多云整合到其任务关键型工作负载中。

这让你不高兴了吗？如果是这样的话，你可能并不孤单。与专家(包括我自己)交谈，他们会告诉你多云是如何误入歧途、目光短浅、天真、没有好的Doo策略。

事实上，很难找到拥护多云的文章，而这些文章不是由有东西可卖的组织推动的。相信我，我试过了。无论如何，尽管似乎只有销售宣传才能支撑它，但多云正在成为(已经成为？)。一个行业标准。

这是怎么发生的？整个行业如何围绕一个不符合云专家共识观点的战略进行转型？如果它被广泛采用也不会那么糟糕，不是吗？

假设它真的那么糟糕，有没有办法从整体上重新思考这个概念，并让它真正变得好呢？

今天，我将回答这两个问题。为了让每个人都恨我，我将尝试一举揭穿并验证多云。

在深入讨论多云之前，让我们退一步来评估一下它到底是什么。重要的是，不要将其与从多个提供商(无论是Office365还是GSuite)使用基于云的服务的组织混淆(您会惊讶IT领导者犯这种错误的频率-请给我买一杯苏格兰威士忌，我会告诉您谁应该为此负责)。

当我谈到多云战略时，我指的是组织在多个云平台上积极部署其工作负载的战略。值得注意的是，术语“云平台”并不区分私有云和公有云，这意味着“混合云”隐含地包含在多云的概念中。

你可能注意到这个定义非常宽泛。因此，有许多不同的方法可以将多云作为一个概念来实现--然而，在现实生活中，最常见的方法是基于一种旨在避免供应商锁定的策略，称为云不可知论。

云不可知论是一种设计解决方案的实践，这些解决方案仅利用组织使用的所有云平台所共有的功能，即它们在功能上的最低公分母。这样，任何工作负载都可以从云迁移到云，甚至可以同时在所有云上运行，理论上可以无缝迁移到提供最佳性能指标(通常是成本)的云平台。

根据组织对维护私有云可移植性的热衷程度(而不是全力以赴在公共云上)，以及组织是否愿意将部分控制权让给云服务提供商(例如，选择托管数据库服务来托管数据库，而不是提供在专用主机上部署和管理数据库软件的DBA团队)，最低公分母的设计可能意味着不同的事情。

旨在保持私有云可移植性的云不可知策略通常会将设计选项限制为传统数据中心功能集附近的功能-本质上将云视为具有突发容量的无差别VM场。不愿通过利用公共云上的托管产品来放弃控制权的组织也会更喜欢这种方法，而不管他们使用的是私有云，因为这是云不可知论的“最真实”形式。

放弃私有云可移植性并愿意采用托管产品的组织可以访问更广泛的合格选项目录-云之间共享的任何功能都是公平的。然而，他们利用这些服务的能力直接取决于在抽象不同平台的API方面投入了多少精力。例如，每个公共云平台都提供托管数据库服务，但提供这些服务需要与截然不同的API交互，并选择所有API通用的数据库引擎。平台的抽象化通常通过投资Terraform或Pulumi等不可知的基础设施即代码(IAC)工具来实现，或者(不常见的)通过利用多云管理平台(如Morpheus Data或Flexera/RightScale)来实现，这些平台的既定目标是抽象特定于云的概念，并帮助将工作负载定义为与云无关的基础设施单元。

现在我们了解了多云是什么，让我们来看看它为什么会出现。走多云路线背后的理由是合理的，至少乍一看是这样。你经常会看到的高价商品包括：

避免供应商锁定-“我可以随时离开(因为我对云是不可知的)”

获得一流的服务-“为正确的工作选择合适的工具(这可能意味着最好的，也可能意味着最便宜的，取决于您的优先事项)”

停机时的恢复能力--“万一A坏了，我还在B上。”

地理覆盖范围-“其中只有一家的DC接近我的客户/在我的合法数据驻留参数范围内”

关于合规性的含糊其辞--“我真的没有引用这句话，但我经常看到它没有明确的定义，所以我还是在这里列出了它。”

它们通常归结为风险管理、降低成本和性能优化措施。这有什么问题吗？

嗯，事实证明，许多这些昂贵的项目都源于对云的毫无根据的假设，这些假设源于传统的IT实践。

正如许多专家会告诉你的那样(科里·奎恩比大多数人更有说服力)：

正如我们在前面介绍的，通过坚持云不可知论来避免供应商锁定会将您的设计选择限制在最低的公分母；换句话说，既不是最好的，也不是最便宜的，这完全使最佳的论点无效。

将你的花费分散在几个云中只会阻碍你的谈判筹码，而不是帮助它。企业在公共云中的折扣相当公式化，而且随着您的总预期云支出的增加，折扣会越来越大。“威胁”花费较少的云服务提供商只会削弱你的地位。

在单个公共云中，您可以非常有弹性。全区域停机很少见(尽管Azure最近尽了最大努力来证明我是错的)，但是跨多个区域的多个可用区部署您的工作负载应该会给您的SLA提供足够的9个来覆盖大多数(如果不是全部)情况。

地理覆盖的论点在云的早期是有效的，但各供应商之间的重叠已经变得如此之大，以至于它基本上已经失效了。

好吧，那么，如果云专家很明显地认为这些假设是错误的，为什么它们会如此普遍呢？嗯，这很简单，因为没有足够的云专家来驳斥这些假设，无论它们出现在哪里。不要只相信我的话(虽然你应该相信，但我已经广泛地体验了那个特定的痛点)：你可以找到几年前的一项又一项调查，概述了该行业缺乏云专业知识的情况。将这一点与无处不在的云采用进行对比，就很容易理解该行业可能会呈现出与直觉相反的趋势。

然而，这并不能完全解释采用多云的规模。不，要做到这一点，你必须求助于一种更加邪恶的力量：

由于无法在服务广度上与三大巨头正面竞争，后来者反而看到了通过利用这些普遍存在的假设为自己瓜分市场的机会。通过支持多云方法，他们可以继续销售云服务，而无需超越市场领先者-云不可知论有效地保护了他们不受差异化服务产品的影响。由于这些参与者中的大多数已经从过去与他们打交道(无论是在虚拟化、硬件、Colo或其他方面)中获得了IT领导者的信任，因此将自己定位为值得信赖的云顾问是一项相对容易的任务。

需要说明的是，虽然我确实在上面开过玩笑，但我并不是在暗示那些组织是故意误导的。恰恰相反，他们只是在他们迟来的市场上看到了一个便利的、需求高度旺盛的缺口，并机会主义地填补了这个缺口。

现在你就知道了。在迫切需要云专业知识的市场和过多的机会主义供应商的交汇处，您会看到多云的激增。

就这样了，对吧？多云是从无知中诞生的，因此它是不好的，每个拥护它的人都应该感到不好，案例结束了吗？当然不是。

虽然人们很容易忽视大多数通常被鹦鹉般的多云谈话要点，但其中一个很突出，很难一概而论地抛弃：

获得一流的服务-“为正确的工作选择合适的工具(这可能意味着最好的，也可能意味着最便宜的，取决于您的优先事项)”

为了验证多云作为一种战略的有效性，云平台需要在一些重要而又足够具体的方式上脱颖而出，而不是简单地将整个业务转移到其他地方。

知道每个云提供商如何非常努力地覆盖其他云提供商所做的相同领域，是否存在这样的情况：一个平台在一件事情上做得比其他平台好得多，以至于有理由在它上面使用多云，而不是直接转向它？

早在4月份，Zoom就达成了一项协议，将其很大一部分基础设施迁移到Oracle云。这一举动引起了整个行业(包括我的)的质疑，因为甲骨文云并不是真正的市场领先者。直到才华横溢的科里·奎恩(是的，又是这个人，他值得一读)才让我明白为什么。简而言之：Oracle云在出站数据方面很便宜。非常便宜。比方说，比AWS便宜一个数量级，基本上Zoom所做的就是把数据发送给它的用户。根据甲骨文的数据，每天有7拍字节，这是一个巨大的数字。0.0085美元/GB的价格是255000美元/月，而aws的价格是150万美元/月(使用他们最具竞争力的公开定价级别)。这相当于节省了83%的成本，比你仅通过企业折扣可以节省的成本还要多(如果可能的话，Zoom会做到这一点的)。哦，更重要的是，这是使用公开定价，对于这种规模的交易，Zoom绝对不会支付。

当然，这并不意味着Oracle云作为一个整体比其他平台更好(事实并非如此)。这确实意味着，对于他们的视频流工作负载的特定要求，甲骨文云大幅降低的传出数据定价是游戏规则的改变者-正确的工作的正确工具。

这向我们表明，最好的观点至少有一定的合法性。云平台(那不是市场领导者！)。对于特定类型的工作负载，它表现出明显优于其他选择的特点。事实上，它是如此卓越，以至于它为在一个已经在另一个云上成功操作其工作负载的组织启用多云提供了坚实的业务案例。

人们可能会忍不住认为这个例子是侥幸而不屑一顾的。整个行业都对Zoom的举动感到惊讶和困惑，这一简单的事实应该会告诉你，这在某种程度上是一个异常值。毕竟，自多云技术问世以来，人们就一直在争辩说，多云技术能够实现最佳的服务选择；如果这是真的，那么就会有数百次放大，在云中移动会带来巨大的收益。现在有什么不同呢？

差异化云直到最近，云供应商还在朝着相同的目标竞相前进。在AWS赚钱前景的诱惑下，他们每个人都想成为这个平台。这意味着，基本上是在追赶AWS，将“即服务”附加到您现有的产品目录中，并将其作为杠杆，将您现有的客户群转变为云市场份额。因此，围绕云的概念出现了巨大的趋同--除了少数例外(我想到的是谷歌)，AWS有创新的回旋余地，而它的竞争对手大多只是模仿它。

最终，Azure在所有意图和目的上都赶上了AWS，使得这两家公司不断在不断增长的服务广度上争先恐后地超越对方。在这一点上，任何球员，无论领先与否，都不太可能毫不含糊地将其他球员甩在身后。

一个接一个地，云服务提供商开始接受这样一个事实，即他们没有资源或牵引力来实现或维持前两名那样广泛的范围-即使他们做到了，“仅仅”像他们一样优秀也不足以保证他们的行动。这使得他们只有两个选择：改变他们的方法(比如VMware在混合云上全力以赴)或者专门化他们的产品(比如GCP重新专注于数据分析和少量业务垂直市场)。换句话说，让自己与众不同。

事实上，GCP专门化的决定是我们需要注意的。作为“三大”之一，尽管采用率最低，但GCP的行为最有可能告诉我们，当Azure和AWS的市场份额停止爆炸性增长时，它们可能会走向何方。除此之外，GCP的专长也特别值得注意，因为它可能会塑造市场上规模较小的参与者如何做到这一点。他们是怎么做到的？通过支持多云的日益完善的PaaS产品。

PaaS将是他们的出路，这是有道理的(而不是，比方说，试图在CPU/GPU性能和定价方面单打独斗)。PaaS是他们利用其丰富的内部专业知识并将其打包为客户的纯托管云本地服务的最便捷方式。市场也看到了这一点-随着组织越来越深入地采用云，我们看到越来越多的人采用PaaS产品。

它之所以引起如此大的共鸣，可以追溯到行业内云专业知识的枯竭。任何可以增加功能和降低运营费用的东西通常都是好的，但在资源匮乏的行业中，这就变得至关重要。当您可以让他们专注于创造新的业务价值时，花费您宝贵的少数资源来重新发明轮子并运营您的基础设施是没有意义的。

市场上已经有了验证GCP迈向差异化PaaS的势头。Snowflake和Wasabi等规模较小的云服务提供商通过提供高度专业化的PaaS解决方案获得了很大的吸引力，并明确将自己定位为较大公司的个别服务的竞争对手，从而将自己用于多云模式。

随着市场不再试图简单地模仿大公司，转而转向完全差异化的产品，我们将达到这样一个地步，即“做多云”将意味着从一系列最佳的云本地服务中透明地组合解决方案-这实际上是一个很好的多云战略。

当然，到目前为止，我们所做的一切都是在争辩说，多云可以是一件好事。精挑细选每个平台的想法在理论上听起来很棒，从第一天起就是多云的卖点，但如果不能在不牺牲可操作性的情况下实现它，那就没有价值了。毕竟，本机服务互操作性是像AWS这样的平台的最大优势之一，因此，要形成坚实的案例，我们需要建立一个完全建立在利用差异化产品优势之上的战略。

选择“家庭基地”云平台首先，组织应该采用单一的云服务商作为其家庭基地，最好是领先的公有云平台。即使掌握一个云也很困难，资源稀缺，即使是理想的多云场景也至少涉及一些运营开销。在组织能够就它应该采用哪些多云服务(甚至是否应该采用它们)做出明智的决定之前，它应该对其总部有非常扎实的了解。选择总部还会将大部分支出(至少最初)集中在一家供应商上，从而使获得折扣率变得更加可行-进而提供一个优化的价格点，外部服务必须击败该价格点才能证明成本效益。我要指出的另一个不可忽视但难以量化的优势是，在致力于总部时，能够与提供商的资源(代表和客户架构师)建立更紧密的关系。正是通过这些关系，您才能在需要时获得专业知识、资助计划和快速支持。

拥抱云本地服务不言而喻，要充分利用差异化的云服务，我们必须放弃云不可知论作为一种设计模式。如果不致力于云平台的技术(至少以某种形式)，就无法实现云平台的全部价值。这里的“全部价值”可以指更低的成本、更好的性能，或者更重要的是，降低运营开销。在我们所面对的资源紧张的行业中，降低运营管理费用被证明比以往任何时候都更加重要。因此，应该尽可能多地利用托管服务。当然，我并不是在倡导任何像在每个转折点都盲目选择托管服务这样的教条-您应该始终运行一些发现来正确理解它们的限制和成本结构，因为它们可能被证明是令人望而生畏的-但我建议采用托管优先的心态。

采用与云无关的工具由于我们将在我们的云服务中引入更多种类，因此实现规模化运行的唯一途径必须是能够支持整个生态系统的标准化工具。Terraform和Pulumi等不可知的IAC技术已经很成熟，并且具有足够的可扩展性，足以满足大多数基础设施配置需求。然而，我在这里要强调的一件事是，我在工具和工具基础设施之间划了一条线：虽然我告诉您要使用不可知的工具，但我并不是告诉您支持它们的基础设施(例如，您的CI/CD管道)应该是不可知的。我也不一定会将云不可知的工具规则扩展到应用层--我相信标准的应用程序部署模型是一件好事™，但在一个我们牢牢固定在家庭平台上的模型中，我不会排除利用云本地解决方案进行部署(例如，AWS上的ECS、运行在GCP上的云或一般的无服务器)。话虽如此，我还是特意对Kubernetes这样的不可知性编排技术在这个特定的多云框架中的未来角色留下一些模棱两可的说法，因为我认为这个话题值得进行自己的讨论。

建立自动化不可知的治理层随着多云使专用SaaS/PaaS产品在云中的使用变得大众化，治理将变得更加零散(阅读：困难)。虽然报告和审计工具仍将与反应性故障保险相关，但使用中组件的绝对数量和分布将需要更积极主动的法规遵从性和成本运营管理措施。实施这一点的最佳方式是使用策略即代码(Policy-as-Code，PAC)工具作为CI/CD流的一部分，实质上在策略投入生产之前杜绝对其的任何减损。然而，这目前还不是一个有完美解决方案的问题。带有Sentinel的Terraform(至少在Hashicorp Enterprise套件的上下文中)和带有CrossGuard的Pulumi都可以填补这一空白，但它们各自的覆盖范围仍然相当有限，而且它们都没有以任何方式被采纳为行业标准。展望未来，有一个由CNCF支持的有前途的计划，称为Open Policy Agent，它可能最终提供一个可行的开放PAC替代方案。

.