很多从业者有一种很朴素的认知：大企业都应该选择多云。如果你的企业是世界五百强，采购部门定期的让多家云厂商来竞标，谁的报价更有竞争力，就多给它一些采购份额，这样不仅能提升供应链的韧性，也有利于商务谈判。
如果不考虑云平台的巨大粘性，这个想法是很有道理的。但实际上，这不是普遍做法。据我所知，没有任何一家大企业在AWS，Azure 和 GCP之间这么做。原因非常直接：在云平台之间迁移的成本太高了。
云迁移不可行
我本人做过一个云平台迁移项目。由于一个零售业合作伙伴不信任亚马逊公司，要求我们把系统从 AWS 迁移到 Azure，以避免亚马逊窥探其数据。对非工程师来说，这听上去是一个非常，非常，非常合理的要求，但实际上，这个需求是不可落地的。
举例来说，Azure 并没有 Elastic Container Service 服务，所以我们不得不组建一个 Kubernetes 专家团队。即使应用开发者重构代码，Azure 的 CosmosDB 也无法替换 DynamoDB。Azure 的用户权限管理和网络，在模型上就和 AWS 差别巨大，我们在之上构建的合规性和网络安全需要彻底重建。再加上其他服务，最终项目处于这么一个境地：由数据合规驱动的项目，在付出高昂的工程师时间成本之后，反而让系统的合规性下降到不可接受的程度。
我在去年写过一篇文章《多云操作系统：一种幻想》，在理论上对这个失败项目做过总结。
目前整个行业没有一个关于云服务产品的RFC，更不用说国际标准。短时间内期望厂商们协商出一个Cloud POSIX，是不现实的。
从实务角度看，把一朵云当做一个操作系统，轻易不要迁移，迁移则改造应用，听上去很不酷，但是是目前的最佳选择。
瑞典马工所在城市小，可以把主要的云用户和他们的云平台列出来，Spotify， H&M 在 GCP 上，Klarna，Volvo，Scania 和爱立信用 AWS，Sandvik和 Handelsbanken 银行在 Azure 上，非常清晰。
实际存在的多云
工程领域的真理之一就是：理论上最不合理的设置，一定在现实中存在。理论上最合理的设置，一定在现实中不存在。
尽管多云成本巨大收益微小，实际上，不少公司有意无意的采用了多云战略。大概可以分类为
收购/合并引起的多云
集团下每个bu有独立技术决策权
混用不同云的不同服务。比如web service放aws，olap放bigquery。
外包公司
把云当 IDC 用的公司
收购/合并引起的多云
这类是最常见的多云。比如用 GCP 的 P 公司收购了用 AWS 的 Z 公司，不太可能在短时间内把两边的 IT 系统合并。尽管长期目标是迁移到 GCP，但是由于业务继续增长，Z公司甚至还会加强在 AWS的投入。目前，这是最常见的多云动机。
业务线独立运作引起的多云
在某些大公司，每个业务线有自己的技术团队，可以独立做技术选型。尽管在商务上他们是一个公司，但是从云平台的角度看，他们实际上是有不同决策链的多个公司。这种架构面临的一个挑战是，如果监管单位给集团提出更高的合规要求，集团可能要付出很大的努力要在不同技术栈中落地，最终可能推动一个集团“云中台”，以收缩技术线的选型范围。
混用引起的多云
由于所有的云服务都是通过 Restful API调用，理论上，大家是可以混用不同厂商的服务。最常见的是 web services 部署在 AWS 上，OpenAI 的 API 实现 AI，大数据送到 Google BigQuery 去。而BigQuery 又可能通过 S3 Connector 来加载 AWS 上的 Parquet 对象。
这种多云架构，需要团队对多个云的产品有比较深入的了解，能全面的评估方案优缺点，目前不是很普遍。
外包公司的多云
这种多云没有什么可说的。 外包公司比如 Capgemini， 本身对于云平台是中立的。即使他们可能参与技术选型，最终决策也在客户那里。因此外包公司一般都会分开 GCP， AWS 和 Azure 团队，每个团队独立的服务该云上的客户。团队之间可能共享人员，但是没有很多共享的CCOE。
矮化成 IDC 的多云
如上所述，如果甲方应用深入依赖于各个云平台的服务，而不同云平台的服务并不一致，更没有统一的 Cloud Posix 接口，导致甲方很难在云平台之间迁移。很自然的可以推断，如果客户不使用这些服务，则可以避免依赖，进而实现迁移自由。
这样做的客户不少。他们拒绝任何有粘性的高阶服务，只用均质化的虚拟机，Kubernetes服务，CDN，顶多加一个对象存储。其他的，从数据库，到TLS cert，到镜像扫描，到CI/CD，到可观测性，全都自建。
最极端的例子就是哔哩哔哩公司的多云管理平台，他们不仅不用高阶服务，还特意建设一个系统以在不同供应商之间调度流量，彻底把云平台商品化（commoditize）。他们的理由非常朴素
为什么使用多云：
公有云因为其弹性、按需使用以及多地域的覆盖等优势，企业在高速发展的过程中往往会选择公有云来提供应用所需的基础设施；
为了高稳定性和成本最优的考虑，一般会引入多家云厂商；
多云部署防止单一云厂商故障导致服务完全不可用；
采用多云也提升了采购上的议价能力，避免单一厂商绑定，在价格谈判中处于劣势；
不同的云厂商在覆盖的地域、产品的能力上不一致，引入多云可以充分发挥各厂商的服务能力和产品优势。
中国绝大多数企业客户上云都是这样的，包括淘宝上阿里云，腾讯游戏上腾讯云，也避免任何绑定。
我无法从商业角度评判这种策略。但是从工程角度看，这种做法会导致甲方投入大量的人力自建一些低质量的 PaaS/平台/中台。我可以很有信心的推断，哔哩哔哩公司内部有一个数据库平台，他们要么用 DBA 肩扛背挑，要么就在用Python写一个简陋的 RDS 服务以实现基本自动化，尽管他们的 RDS 和专业厂商的相比就是一个玩具。消息队列，Kubernetes，配置管理，负载均衡，情况都应如是。说得坦率一点，B站本来应该去开发 App 的工程师，在用开源软件自己攒一个劣质云。
对这种策略，我的朋友titi做过严肃的技术批评，有两篇文章大家可以参考
我的一篇旧文也可以参考
总结
云计算作为一个工程领域，有很多细微但是重要的knowhow。我经常听到一些从业者做如下论断
大公司嘛，肯定要避免供应商绑定，多云是必须的。
苹果公司都会把外包分别交给富士康和伟创力，你怎么能把所有的宝都压在阿里呢。
All in AWS的话，AWS中国崩溃/破产/跑路的话，那我怎么办？
应该说，这些说法都有一定的道理，但是工程领域不是物理学，并不追求完美，只追求限定时间内能够达成的最高的投资回报。在当前的工程局限下，All in一朵云的投资收益比远远大于多云替换。也许过个十年，美国政府标准局重拾他们的 POSIX 动议，为云 API 制定一个采购标准，那时候我们就可以搭便车低成本的做多云迁移了。
