B站公众号所发布的那篇《B站多云管理平台建设》引发诸多公众号所转载。文章的主要观点为：企业在IT建设过程中，选择多云有诸多好处，但是也带来了一定的管理复杂度问题，于是便建设了一套云管平台去管理不同的云资源，并着重介绍了各个模块的建设过程。该文中关于多云优势的许多观点以及解法都令我感到困惑，但静下心分析，能意识到这类想法很早便已扎根互联网，还是很有必要聊一聊的。（本文仅代表个人立场）
多云是指利用多个不同的云服务提供商的云计算资源来支持企业应用的部署和服务。这种环境可以包括公共云、私有云和混合云，以及不同的云服务提供商。为了尽可能避免观点发散，本文中所讨论的多云，指同时使用多家公共云厂商，不涉及私有云、混合云的多云场景讨论。
企业选择将多云作为自身IT发展的必要途径时，会有许多的考量，如政策影响、商务合作、技术领先性以及稳定性等。对于实际的IT管理者以及从业人员来说，由于需要同时管理来自于数家云厂商的产品，存在着更高的学习及管理成本，因此一种美好的幻想是通过自建云管平台（CMP）对各家云厂商的底层资源进行封装，然后通过上层平台统一管理云资源。这种做法也在近几年CNCF所致力打造的技术中立的生态之下，逐步成长为主流意识形态。用户通过将应用与底层资源解耦，并封装在容器之中，不仅可以更快捷地完成从线下IDC到线上的转换，同时也可以换成不同云之间的快速部署。
用户多云诉求
在讨论多云场景时，撇开业务场景不谈没有实际意义，首先应该从组织视角分析思考客户的动因。数据安全：随着中美关系的发展，世界正处于一个不确定性的时代，未来诸如滴滴、Tiktok等数据安全事件也会不断出现。各国都在出台相关法律法规对相关数据加以限制，内资企业出海以及外资企业本地化时，由于在相应地区缺少基础设施部署，会引入一些本土的云厂商合作支持。应对不确定性风险：外资云厂商与内资云厂商，有时代表着一种政治正确，而这种逻辑并非基于市场及技术考量。对内，IT负责人会揣测业务部门的倾向性；对外，组织同样也会提早嗅探出市场所面临的潜在危机。商务合作：在国内，各家云厂商背后都会有自己的优势资源，无论是阿里的电商、腾讯的微信还是字节的短视频，都能够给企业带来不容小觑的流量。为此，从商务视角，客户也乐于将众多集团看作是其发展的重要合作伙伴。行业垂直解决方案：过去几年很火的中台建设催生了一批批的业务中台、数据中台项目。对于客户来说，上层服务所提供的价值是其关键所在，而至于部署在哪里，并不重要。诸侯林立：对于一些超大规模的集团公司，尤其是成本独立结算的组织来说，如何用云、用什么云并不完全出于全局利益最大化考虑，组织的背后是人，有人的地方自然就有江湖。对于一些企业内部各方诸侯而言，有若干家云厂商同时存在于不同的部门，更是一种权力角逐。外部环境变化：随着企业经营环境的外部变化，管理者会不断调整其经营策略。在经营困难时，IT资源投入的硬降本压力甚至大于系统稳定性及研发效率，此时，迁云下云成为必然。相反，在业务面临过多次的稳定性风险之后，企业也同样会将业务搬迁到稳定性更高的头部厂商。在此过程中，往往业务要面临很长一段时间的多云共存的阶段。选择权优势：企业在不断扩大规模的过程中也难免会存在一定的不安全感。需要时刻为更糟的情况做出充分的准备，一旦在未来商务合作破裂，那备用方案是什么就很关键。技术原因：有许多客户宣称，引入多云可以充分发挥各厂商的服务能力和产品优势。关于这点，将在后续内容中展开。多云用法
从真正实施落地，多云有三种用法：
用法一：组织同时在和多个云服务商有合作，但相互之间没有调用关系，系统之间完全隔离。
用法二：组织同时在和多个云服务商合作，但相互之间没有深度的集成关系，只是通过 API 做了一些接口，实现数据层面的交换或共享。
用法三：组织同时在和多个云服务商，系统架构强耦合，可以以“分布式架构”实现不同云服务之间的联系与合作。
对于用法三的观点，笔者个人持否定态度，云产品本身存在异构性，即便是在CNCF所推崇的云原生技术标准相对统一的今天，也只是明确了技术栈的基础能力，并不妨碍云厂商在此之上做功能增强，当业务系统用同样的方式完全分布式部署在两朵云上，最后的结果只能是取云特性的最大公约数。由于受限于性能、负载、故障排查等诸多影响，效果也不会理想。相比起优势，会带来更多的复杂度问题，这些在下文中详述。
多云“技术优势”
从真正实施落地，多云有三种用法：
在文章的开头，作者便道出了所在企业为什么要使用多云的三大理由。这恰恰也是本文中最令人费解的几点。
总结一下共三点：
第一点不做详解了，似乎该观点只是基于云的特性论证了为什么要用云而不是多云，如果客户最早上的不是一个假”云“，那基本可以忽略不计，头部的几大厂商都具备这些优势。分别讲下剩余几点：
先说稳定性，多云部署真的能够避免云厂商故障导致服务完全不可用吗？其实并不能。在分布式架构下，情况甚至会更糟。今天之所以有这个错觉，一般是客户自建了所谓的“云”数据中心（此处也可以是一些可用性相对更低的厂商），于是选择了可用性更高的云厂商做多云容灾/多活方案，以应对现有基础设施应对业务稳定性时的问题。于是，当组织接受了这个预期设定，得到的结果反馈一定令人失望的。为了避免单个云厂商故障完全不可用，实际效果只是增加了每个系统部分不可用的风险，业务风险同系统耦合度成正比。对于业务结果来说，一旦某个点出现问题，那么基本上全盘皆跪。在单组件故障场景下，单云和多云的可用性并无二至；但在可用区级别的故障下，多云反而会导致更高的故障发生次数。现实点的情况，也许IT部门本来只需要写1次故障报告，现在要写5次。真正能够提升系统可用性上一个台阶的，核心之处并不在于是否多云部署，而是多可用区。前文已表达了多云部署存在的组件异构问题，使用不同的规格、版本、甚至部署方式，都带来了更多潜在的风险。实际上，但凡做过业务高可用建设的人都知道，一旦发生某个可用区级别的故障，除非对应用做代码层面的单元化改造，尤其是数据库、缓存等，故障来临之后快速对流量切零，否则几乎不可能快速恢复业务。而云产品的异构问题，即便负载均衡器也无法完全做到各云之间功能完全对等，更不用说其它PaaS产品。毕竟，稳定性建设不仅包括容灾，同样也包括应用容错。成本
再看成本，看似是有道理的。但是细究的话，还是能发现这点逻辑上很难站得住：“通过多云战略，避免被单一厂商绑定”。中大规模的企业在决定将一套系统部署在哪家云厂商时，绝大多数情况确实是从成本视角出发，算出部署在哪里更适合，成本更低，于是便将其部署在哪里。首先是适合，其次才是成本。除部分集成度低、通用型产品以外，成本在这里并非是决定性因素，也可以是地域，稳定性等因素。退一万步，也许企业在决策是否使用更多的云平台时，确实有从成本出发的动因，但是从结果上说，多云并没有带来更低的成本，同时还增加了更高的隐性成本（管理成本、学习成本、沟通成本等）。而所谓的议价权，如果文中的观点成立，那么苹果就应该一开始便在中国至少找三家代工工厂。同理，引入的云厂商越多，看似拥有更大的议价权，但是由于需求量的下降，对于议价并没有实际帮助。对于绝大多数非头部用户来说这个观点同样也不成立。综上，成本也许是厂商一开始考虑多云的原因之一，但多云并不能直接推导出会比使用一家云来的更为便宜。多云协同，产品优势
对于这点，与其称之为好处，我更愿意将其视作为企业的一种无奈之举。并且作用域也很有限，一般只有一些可完全与业务系统解耦的云服务如短信、CDN、WAF等外挂服务可将其与业务系统无缝对接。很难想象，今天企业会因为X厂商的某一产品具有显著优势，于是业务部门不遗余力的将应用系统部署在该平台上。多云协同的另一败笔在于网络建设。这点是为什么传统IDC时代最难比拟的优势所在。任何一个中小客户在使用20-30台服务器时，都能够将资源部署在两个可用区，同时获得仅2ms不到的网络延迟，而通常两个IDC之间的网络延迟一般都在5ms左右。对于多云网络架构，也是同理，同时还要负担额外的网络专线成本。多云协同的背后依然是人，在信息传递的过程中，链路越少对于根因定位便越有优势。当一套系统的关键链路中存在两家甚至两家以上的CSP时，一旦涉及到深层的故障排查及根因定位，效率低下难以言表。尤其可见，在该文中作者所列举的几个多云的优势，如果是其初衷，那么结局可以预见是悲观的。
当我们在思考问题的最优解时，考虑获得了什么有时并不能对最后的结果起到直观的判断依据。而放弃了什么，反而更具有参考价值。在团队同时管理三个公共云的情况下，很难保证云上治理能够满足业务发展，数据安全事件频繁发生。当管理人员面对不同的资源管理方式、用户登录、权限治理等一系列繁琐的事务性问题时，几乎处于“躺平”的状态。另一种解决思路，便是企业在各个云之间取最大公约数，仅使用一些基础的几大件，在单一应用的代码中不引入任何SDK并使用云托管服务，除了计算、网络、存储以外的PaaS组件，均需要由运维团队自行搭建完成。究竟是将云平台看作是放置应用的房间还是培育应用的土地，选择前者的本质是企业承担了高昂的溢价成本之后，没有享受任何“平台”优势，发挥出云原生的最大价值。云计算的本质是效率，而这种效率得益于技术产品能力的创新，绝大多数的管理者并没有理解云的真正价值。过去客户如果要实现一套分布式系统的治理能力，可能需要投入一个团队耗时几个月投入建设，而现在即使是规模再小的技术团队，也能够利用诸如MSE实现淘宝双十一级别的应用高可用能力建设。云之所以不同于传统IDC，便在于提供的不再是背后的硬件资源，而是公共服务。这种服务方式涵盖了底层网络、计算、存储资源，也包括了上层平台所提供的账号权限、监控告警、资源管理以及后台排障工具支撑等附加能力，而这也是云资源溢价的关键原因。
部分IT管理者以及多云“布道师”所宣导的未来云的终态。观点大致如下：
在某种程度上，分布式云是多云架构的技术基础和核心，它能够实现多云架构的高可用性、高性能和高度可扩展性，也能更好实现现代化应用的部署编排。没有分布式云的支持，多云架构不能够充分发挥其优势。如，在多云架构中，企业可能需要将应用程序和数据分散到多个云平台上，以满足不同业务的需求。在这种情况下，如果没有分布式云提供的技术支持，企业将难以实现负载均衡和高可用性的保障，而且可能会面临数据一致性、安全性和监管合规性等问题。分布式云可以有效地帮助企业克服这些问题，提高多云架构的可靠性和安全性如上述观点所述的多云会是终态吗？我相信在未来很长一段时间，多云都会是客户选云用云的常态，但可以肯定的是不会是终态。多云在技术层面不存在任何核心优势，也从来都与成本、效率、稳定性不沾边，更谈不上“云原生”，只是“虚拟机”的玩法在云时代下的苟延残喘。其核心问题无法在根本上得以解决。一个有趣的佐证是国内外的诸多厂商都在CMP这条赛道上尝试过，而事实是这些产品的共同特点是大量的人力支出，却都只能纳管一部分的云产品资源，一旦涉及到复杂操作，用户依然需要登录云平台。而随着云产品的种类，云产品功能的变更，无论是CMP厂商，还是客户都难以提早识别到这些问题，后期这些“绩效项目”也都逐步转向烂尾，难以讲清价值。三年前不少厂商所拼杀的赛道，目前幸存者寥寥，也只剩惨淡维持。
瑞典马工约 10 分钟