多云操作系统一种幻想

　　摘要
　　屏蔽不同云平台差异的多云操作系统，听上去很吸引人，但是认真查看各家产品之后，我发现多云操作系统的承诺都是虚假的。踏踏实实选择一朵云，利用云服务能力，提升云原生应用程序的竞争力，是比较务实的选择。统一API是一种幻想
　　隐藏不同云服务API的差异，抽象出一套统一的API供用户使用
　　这是最常见的多云操作系统的宣传。不客气的说，这是一个不动手的外行在试图忽悠另外一个不动手的外行。只要两个人中的任何一个人动手，就会碰到三个无解的问题：各家云提供的服务目录并不一致
　　目前业界并没有任何云服务的RFC或者ISO标准，因此各个云厂家的产品组合差别很大。比如AWS的ElasticContainerService是一个比Kubernetes易用的容器编排服务，但是其他云厂家根本不提供这个服务。而本土主流云厂家都提供的托管Istio服务，AWS则完全不支持。这种情况下，统一API就成了无源之水。对应的服务有不同的模型
　　即使各家云都提供的云服务，其模型也可能千差万别。比如虽然腾讯云的CLB和AWSALB定位一样，但是两者的概念模型差别很大，API的结构也就差别很大。具体可以参考我上一篇文章《究竟是客户差劲，还是腾讯云差劲？》中的分析。
　　这种情况下，硬要提取统一API的话，估计只能提取三个最大公约数：创建LB，查看LB和销毁LB。这种统一API对用户毫无意义。相同的模型有不同的行为
　　由于S3是本行业第一个基础设施云服务，它的API实际上成了对象存储云服务的事实标准，因此提取统一的对象存储API是可能的。
　　但是，在统一API的表面下，各家云厂商提供了不同的行为。比如AWSS3默认对象是跨AZ分布的，而本土三个主流云厂家默认对象存储在单AZ。这个看似微小的差异，可以在故障的时候造成致命的区别：跨AZ的就可以继续服务，单AZ的就可能丢失数据。读者朋友可以参考我的上一篇文章《阿里云的故障在其他云也可能发生，并且可能丢数据》。
　　在这种情况下，提供统一API实际上会误导客户，使其认为云厂商的行为是一致的。实际落地的是一个虚拟机管理平台
　　由于上述问题的存在，落地的多云管理平台实际上都采取了鸵鸟政策：放弃对多个服务提供抽象API，专注于提供虚拟机服务的统一API。
　　《作业帮多云架构设计与实践》里就直白的说，为了避免供应商绑定，连RDS都不用，只用云厂商的虚拟机和网络，然后自己维护Kubernetes集群。
　　但是，虚拟机统一API也是价值最低的。如果用户只需要虚拟机，用vSphere或者Kimchi管理托管机房的物理机不就好了，何必用单价更高的云？Terraform不提供统一模型
　　有人声辩，主打多云的hashicorp公司的Terraform做到了多云无感知的资源管理。
　　这是个很常见的误解，实际上Hashicorp官方文档明确的表示：
　　Terraformitselfintentionallydoesnotattempttoabstractoversimilarservicesofferedbydifferentvendors，becausewewanttoexposethefullfunctionalityineachofferingandyetunifyingmultipleofferingsbehindasingleinterfacewilltendtorequirealowestcommondenominatorapproach。
　　Terraform本身有意不尝试对不同供应商提供的类似服务进行抽象，因为我们想要公开每个产品的全部功能，而将多个产品统一在一个接口后面往往需要一种最小公分母方法。
　　https：developer。hashicorp。comterraformlanguagemodulesdevelopcompositionmulticloudabstractions
　　动手写一个terraform模块就能验证上述说法：对应阿里云虚拟机的是alicloudinstance，而对应AWS虚拟机的是awsinstance，terraform就没有genericcloudvminstance这个资源。Kubernetes不是云操作系统
　　前几年有些厂家对Kubernete的期望很高，宣称它是CloudOS，能帮助客户做到云厂商之间的自由迁移。
　　但Kubernetes离云操作系统差了十万八千里。
　　就以一个简单的webservice为例，它在接入端需要CDN，WAF，APIGateway，在计算层需要LB，容器，在数据层需要Cache，块存储对象存储，消息队列和数据库。
　　这个简单场景下，Kubernetes能提供的只有LB，容器和块存储。所有其他的基础设施，Kubernetes都提供不了。这个残缺的平台，显然不能称之为一个云操作系统。实际上，Kubernetes更像是POSIX的分布式版本，是对传统操作系统的一个粗暴的分布式模仿，而忽视了云计算极大的扩充了基础设施能力这个显著事实。
　　如果把场景再做复杂一点，比如引入网络隔离以增强安全性，引入policyascode以增强合规性，引入多区域以提高灾备能力，引入Jupyternotebook以利用AI，Kubernetes就更有心无力了。
　　当然Kubernetes有强大的扩展能力，比如Crossplane和KubeVela都试图通过KubernetesAPI来管理云资源，但这仍然是一条还在探索中的路子。并且，即使能行得通，Kubernetes也无法屏蔽云平台的差异。接受云平台的不同
　　目前整个行业没有一个关于云服务产品的RFC，更不用说国际标准。短时间内期望厂商们协商出一个CloudPOSIX，是不现实的。
　　从实务角度看，把一朵云当做一个操作系统，轻易不要迁移，迁移则改造应用，听上去很不酷，但是是目前的最佳选择。
　　实际上，这也不是什么奇怪的选择，几乎每个IT团队的客户端都有Android版本，iOS版本和浏览器版本，而几乎没有团队使用号称跨平台的QT。
　　有朋友说，用一朵云会被供应商绑定，价格谈判上处于不利位置。这个说法有一定道理，但是供应商绑定并不是个技术可以解决的问题。用Oracle会被甲骨文绑定，但是银行IT团队不会限制自己只用标准SQL以保持在MySQL，PG和Oracle之间的迁移自由。用Windows会被微软绑定，但是强迫普通人用Linux桌面是不人道的。坐高铁会被国铁集团绑定，但是没人会选择开车从北京去海南省过冬吧。
　　回顾历史，当初Linux2。5。44推出epoll系统调用的时候，它也不是POSIX合规的，也就意味着你用epoll的代码就会被Linux绑定，再也无法迁移到其他Unix了。Apache选择了忽视这个系统调用，而Nginx则全面的拥抱这个系统调用。后面发生的事情我们都知道了，功能强大又可以多平台迁移的Apache由于性能太差，被Nginx大面积的取代。
　　绝望者的悲歌
　　云厂家正在疯狂抢传统供应商的饭吃。
　　传统供应商一开始主张云并不适合大企业，从2013年被AWS证伪了。
　　后来他们又主张私有云也是云，但是用户发现私有云与云的差别，和机器人与人的差别一样大。
　　再后来他们退步：企业上云也行，但是应该保留自己的机房，上个混合云，但是现在越来越多的客户根本不想运维机房了。
　　现在这群人被逼到墙角了，又发明了多云统一操作系统的概念，可惜只见PPT不见产品。
　　一路的节节败退，无非就是想继续混口饭吃。作为云用户，我们对他们固然报以同情，但是业务上只能敬而远之。您可能感兴趣阅读
　　究竟是客户差劲，还是腾讯云差劲？
　　腾讯云阿里云做的真的是云计算吗？从客户成功案例的视角
　　阿里云的故障在其他云也可能发生，并且可能丢数据