摘要

屏蔽不同云平台差异的多云操作系统， 听上去很吸引人，但是认真查看各家产品之后，我发现多云操作系统的承诺都是虚假的。踏踏实实选择一朵云，利用云服务能力，提升云原生应用程序的竞争力，是比较务实的选择。

统一API是一种幻想

隐藏不同云服务API的差异，抽象出一套统一的API供用户使用

这是最常见的多云操作系统的宣传。不客气的说，这是一个不动手的外行在试图忽悠另外一个不动手的外行。只要两个人中的任何一个人动手，就会碰到三个无解的问题：

各家云提供的服务目录并不一致

目前业界并没有任何云服务的RFC或者ISO标准，因此各个云厂家的产品组合差别很大。比如AWS的Elastic Container Service是一个比Kubernetes易用的容器编排服务，但是其他云厂家根本不提供这个服务。而本土主流云厂家都提供的托管Istio服务，AWS则完全不支持。这种情况下， 统一API就成了无源之水。

对应的服务有不同的模型

即使各家云都提供的云服务，其模型也可能千差万别。比如虽然腾讯云的CLB和AWS ALB定位一样，但是两者的概念模型差别很大，API的结构也就差别很大。具体可以参考我上一篇文章《究竟是客户差劲，还是腾讯云差劲？》中的分析。

这种情况下，硬要提取统一API的话， 估计只能提取三个最大公约数：创建LB，查看LB和销毁LB。这种统一API对用户毫无意义。

相同的模型有不同的行为

由于S3是本行业第一个基础设施云服务，它的API实际上成了对象存储云服务的事实标准，因此提取统一的对象存储API是可能的。

但是，在统一API的表面下，各家云厂商提供了不同的行为。比如AWS S3默认对象是跨AZ分布的，而本土三个主流云厂家默认对象存储在单AZ。这个看似微小的差异，可以在故障的时候造成致命的区别：跨AZ的就可以继续服务，单AZ的就可能丢失数据。读者朋友可以参考我的上一篇文章《阿里云的故障在其他云也可能发生,并且可能丢数据》。

在这种情况下，提供统一API实际上会误导客户，使其认为云厂商的行为是一致的。

实际落地的是一个虚拟机管理平台

由于上述问题的存在，落地的多云管理平台实际上都采取了鸵鸟政策：放弃对多个服务提供抽象API，专注于提供虚拟机服务的统一API。

《作业帮多云架构设计与实践》里就直白的说，为了避免供应商绑定，连RDS都不用，只用云厂商的虚拟机和网络，然后自己维护Kubernetes集群。

但是，虚拟机统一API也是价值最低的。如果用户只需要虚拟机，用vSphere或者Kimchi管理托管机房的物理机不就好了，何必用单价更高的云？

Terraform不提供统一模型

有人声辩，主打多云的hashicorp公司的Terraform做到了多云无感知的资源管理。

这是个很常见的误解，实际上Hashicorp官方文档明确的表示：

Terraform itself intentionally does not attempt to abstract over similar services offered by different vendors, because we want to expose the full functionality in each offering and yet unifying multiple offerings behind a single interface will tend to require a "lowest common denominator" approach.

Terraform 本身有意不尝试对不同供应商提供的类似服务进行抽象，因为我们想要公开每个产品的全部功能，而将多个产品统一在一个接口后面往往需要一种“最小公分母”方法。

https://developer.hashicorp.com/terraform/language/modules/develop/composition#multi-cloud-abstractions

动手写一个terraform模块就能验证上述说法：对应阿里云虚拟机的是alicloud_instance，而对应AWS虚拟机的是aws_instance， terraform就没有generic_cloud_vm_instance这个资源。

Kubernetes 不是云操作系统

前几年有些厂家对Kubernete的期望很高，宣称它是CloudOS，能帮助客户做到云厂商之间的自由迁移。

但Kubernetes离云操作系统差了十万八千里。

就以一个简单的web service为例，它在接入端需要CDN，WAF，API Gateway，在计算层需要LB，容器，在数据层需要Cache，块存储/对象存储， 消息队列和数据库。

这个简单场景下，Kubernetes能提供的只有LB，容器和块存储。所有其他的基础设施，Kubernetes都提供不了。这个残缺的平台，显然不能称之为一个云操作系统。实际上，Kubernetes更像是POSIX的分布式版本，是对传统操作系统的一个粗暴的分布式模仿，而忽视了云计算极大的扩充了基础设施能力这个显著事实。

如果把场景再做复杂一点，比如引入网络隔离以增强安全性，引入policy as code以增强合规性，引入多区域以提高灾备能力，引入Jupyter notebook以利用AI，Kubernetes就更有心无力了。

当然Kubernetes有强大的扩展能力，比如Crossplane和KubeVela都试图通过Kubernetes API来管理云资源，但这仍然是一条还在探索中的路子。并且，即使能行得通，Kubernetes也无法屏蔽云平台的差异。

接受云平台的不同

目前整个行业没有一个关于云服务产品的RFC，更不用说国际标准。短时间内期望厂商们协商出一个Cloud POSIX，是不现实的。

从实务角度看，把一朵云当做一个操作系统，轻易不要迁移，迁移则改造应用，听上去很不酷，但是是目前的最佳选择。

实际上，这也不是什么奇怪的选择，几乎每个IT团队的客户端都有Android版本，iOS 版本和浏览器版本，而几乎没有团队使用号称跨平台的QT。

有朋友说，用一朵云会被供应商绑定，价格谈判上处于不利位置。这个说法有一定道理，但是供应商绑定并不是个技术可以解决的问题。用Oracle会被甲骨文绑定，但是银行IT团队不会限制自己只用标准SQL以保持在MySQL，PG和Oracle之间的迁移自由。用Windows会被微软绑定，但是强迫普通人用Linux桌面是不人道的。坐高铁会被国铁集团绑定，但是没人会选择开车从北京去海南省过冬吧。

回顾历史，当初Linux 2.5.44推出epoll系统调用的时候，它也不是POSIX合规的，也就意味着你用epoll的代码就会被Linux绑定，再也无法迁移到其他Unix了。Apache选择了忽视这个系统调用，而Nginx则全面的拥抱这个系统调用。后面发生的事情我们都知道了，功能强大又可以多平台迁移的Apache由于性能太差，被Nginx大面积的取代。

绝望者的悲歌

云厂家正在疯狂抢传统供应商的饭吃。

传统供应商一开始主张“云并不适合大企业”， 从2013年被AWS证伪了。

后来他们又主张“私有云也是云”，但是用户发现私有云与云的差别，和机器人与人的差别一样大。

再后来他们退步：“企业上云也行，但是应该保留自己的机房，上个混合云”，但是现在越来越多的客户根本不想运维机房了。

现在这群人被逼到墙角了，又发明了多云统一操作系统的概念，可惜只见PPT不见产品。

一路的节节败退，无非就是想继续混口饭吃。作为云用户，我们对他们固然报以同情，但是业务上只能敬而远之。

您可能感兴趣阅读

究竟是客户差劲，还是腾讯云差劲？

腾讯云阿里云做的真的是云计算吗?--从客户成功案例的视角

阿里云的故障在其他云也可能发生,并且可能丢数据