迈向现代化的云计算（一）
我们之前用了电气化在工业制造领域的推广普及来论证当前云计算在中国尚未体现出它应有的革命性，那么我们需要什么样的云计算？或者说，云计算到底应该是什么样子的？它的首要目标用户应该是谁？
我们知道，宇航员进入太空以后会处于失重状态，最近的两位超级富翁的私人太空旅游演示特别为我们展现了这种神奇的体验：
那么要练习在失重状态下移动身体或是操作各种设备，是不是只能去太空呢？并不是，我们在大气层内也可以人为制造出“失重”的环境，那就是借助于专门的失重飞机：
失重飞机的原理也很简单，经过改造的飞机爬升一定高度后快速俯冲，使人处于自由落体状态，此时飞机由于自身也在向下，无法向人体提供支撑力，使得人体感到摆脱了地球引力的束缚进入失重状态：
这种人造失重环境的原理最早由爱因斯坦总结为等效原理：
引力场中一切物体都具有同一的加速度，这条定律也可表述为惯性质量同引力质量相等。
爱因斯坦设计的一个思想实验是，假想一个在摩天大楼内部自由下落的电梯，里面有一个人。这人让他的表和手绢同时落下。会发生什么呢？对于一个电梯外以地球为参照系的人来说，表、手绢、人和电梯正以完全一致的速度下落。所以表和地板，手绢和地板，人和表，人和手绢的距离固定不变。因此对于电梯里的人而言，表和手绢将呆在他刚才扔它们的地方，他会认为所处的环境是失重的（当然最终他会摔死）。
我们把电梯搬运到一个远离任何大质量的物体的地方，比如，宇宙深处。上一次实验中的倒霉蛋侥幸逃生成功，在医院呆了几年后，又被我们装进了这部电梯。我们在电梯上方安装一个火箭，向上拖动电梯。牛顿力学告诉我们：恒力将产生恒定的加速度。由此，电梯将对内部的物体施加一个加速度。我们的倒霉蛋呆在电梯里让他的手绢和手表下落。电梯外静止的人认为手表和手绢会撞到地板上。这是由于地板因其加速度而向它们（手绢和手表）撞过来。另一方面，电梯里的人会注意到他自己和他的手表、手绢有相同的加速度，他会认为自己处于引力场之中。
等效原理的核心在于，我们无法区分一个重力场和一个加速度坐标系中的物理有什么不同时可以认为二者遵循相同的物理法则。在太空和在向下俯冲的飞机中我们体验到的是一致的失重体验，而电梯中的倒霉蛋无法分辨自己是被火箭拖行在茫茫宇宙空洞中，还是在地球上平稳地运行，这两个环境里所展现的物理是等效的。
等效原理有什么证明吗？我们再对思想实验中的电梯做一个改造，这时电梯壁上有一个小孔，从外部有一束光穿过这个小孔打在对面的墙上。
假如实际场景是火箭正在快速拖动电梯运行，那么由于光线穿越电梯内部也需要一定的时间（很短，但仍然需要时间），所以电梯里的人会观测到光线的照射点在对面小孔稍下一点点的位置上，看起来光线是被弯曲了一点点的。
但是根据等效原理，这个环境也可以被解释成电梯下方存在一个巨大的引力源，那么这时我们也应该观测到一样的物理法则，一样的光线被弯曲。所以根据等效原理，我们可以预言引力会弯曲光线，而这一预言随后已经被人类观测到（太阳巨大的引力扭曲了附近的光线）。该观测也是爱因斯坦广义相对论的首次实证。
尝试用等效原理寻找云计算的首要目标用户
云计算的首要目标用户是谁？云计算对谁来说更加有价值？假设我们在某种受控场景下无法区分出我们当前正在使用的是公有云还是自有数据中心，那么我们可以生搬硬套等效原理（这种生搬硬套没有科学依据，只为阐述个人观点），认为二者在该场景下没有本质区别；而当我们很肯定当前使用的不是自有数据中心，并且是依据某种正向的价值时，我们可以说这种场景下的用户是云计算的目标用户，云计算对他们来说更具价值。
角度一：从终端用户角度出发
假设我们为用户开发了一个手机App，一个无技术背景的手机用户能够单纯凭借对App的使用体验就能分辨出该应用的后端是运行在一个自有数据中心还是在公有云上？我们会发现，在通常情况下，这是非常困难的；偶尔在发生流量尖峰的时候，或许这位用户会体验到卡顿和加载速度低下，这时如果用户有一定的技术背景，他也许会猜测这可能是承载应用的自有数据中心来不及扩容导致的，但这并没有确实的凭据。一个拥有优秀架构设计的公有云应用可能设计了足够强大的自动伸缩策略和灾备策略，使得出现偶发的合理的流量尖峰时可以自动扩容，而终端用户感知不到这个流量尖峰。当然，一个拥有大量冗余资源的自有数据中心也可以做到这一点。
我们可以这么说，作为终端用户，我们很难分辨出正在使用的应用是运行在自有数据中心还是在公有云上的。
角度二：从成本角度出发
企业的数字化系统既可以运行在自有数据中心的裸金属服务器上，也可以完全运行在公有云上。假设一家企业既有自建的数据中心，也使用了公有云，一位无技术背景的高管并不知道自己公司的核心系统运行在哪里，这时他面前摆上了一张账单，账单的内容大概是过去五年里，该核心系统的带宽消费xxx元，16核32G服务器消费xxx元，某某数据库服务费xxx元，他是否能够分辨出该系统运行在自有数据中心，还是在公有云上？
直接迁移（Lift And Shift）模式上云的特点就是将原有的系统架构原封不动地从本地环境迁移到云端，所以即使应用运行在云端，也会呈现出与运行在本地数据中心时相同的模式。从成本方面考虑，一个适应于自有数据中心静态的基础设施的应用，其在公有云上所使用的资源也将是相对来说更容易预先规划的，更适合采用包年包月等付费方式以获取更低的价格。这时从账单看来，都是类似服务器、带宽、磁盘等“硬”资源的费用
当然，如果一个有技术背景的高管在账单中频繁看到了诸如“Spot竞价实例”、“对象存储”、“Faas函数计算服务”这样的服务产生的费用，那么他就可以断定该系统目前主要是用的是公有云，但这要求应用程序是面向云计算环境开发的。
如果团队实际上是用例如Rancher等工具，搭配公有云的虚拟机，在云端构建了一个K8s集群呢？或是使用公有云平台提供的K8s服务创建了一组虚拟机集群构建的K8s集群（例如Aws EKS without Fargate），这时我们在账单上会看到什么呢？我们可能看到的仍然是带宽和服务器的消费科目。
站在成本的角度观察，我们会发现应用的设计架构会影响到我们观察到的成本特征，即使我们使用的是诸如K8s这样的云原生技术，也有可能在成本上呈现出与自有数据中心相似的特征。
角度三：工程团队的角度
假如我们使用的是公有云，然后要求工程团队必须登录公有云平台的Web界面才能接触到基础设施，那自然团队立即就可以判断他们正在使用的是公有云，但这种分辨属于作弊，所以请允许我做一个限制，我们必须在某种程度上限制团队对基础设施的操作方式，例如不能直接访问公有云平台的Web界面，或者是使用VMware等私有云产品提供的工具。
许多公司的工程团队还会有一个专门的基础设施团队来维护所有的基础设施（可能叫运维团队），该团队服务所有的应用交付团队。假如说基础设施团队只对外提供了一个工单系统，应用交付团队通过工单来提交对基础设施的操作申请，比如申请、释放虚拟机、公网IP和带宽等资源，那么此时我们完全无法分辨我们正在使用的是自有数据中心还是公有云。
我们略微放松一些限制，提供了一些API和命令行工具以及SDK，使得应用交付团队可以用代码和脚本来操作基础设施，这时至少我们可以排除这是一个完全由裸金属服务器组成的最传统的自建机房，它至少存在着一定程度上的私有云管理功能，当然这也可能是某个多云管理平台对某个公有云平台的API的封装，我们很难分辨这是一个私有云还是一个公有云。当然，API所暴露出的功能中动态弹性的功能越多，具有Paas性质的功能越多，我们可以认为它是一个公有云的可能性就越大，但现在不少私有云平台在功能上也是非常强大的，但越多细颗粒度高度弹性（Serverless化的Faas就是一个典型例子）功能可以帮助我们排除掉大多数落后的私有云，使得我们愈发趋向于相信这是一个公有云（或是一个非常现代化的私有云）。
假如工程团队得到的是一个K8s Web Console，可以自助申请一些K8s资源（账号、Namespace等），随后可以用kubectl自行维护在该K8s集群上的部署，我们是否能够分辨出这是一个私有云上的K8s，还是公有云上的K8s？有些公有云托管的K8s集群允许我们通过云平台指定的StorageClass挂载分布式存储，也可以通过各种专有的annotation来得到各种扩展能力，除却这些与云平台硬绑定的特性以外，有没有其他可供区分的特征？
某些公有云使用virtualkubelet实现Serverless的容器，例如Aws EKS可以搭配ECS Farget，阿里云也有Serverless K8s(ASK)；但像阿里云ASK这样的Serverless K8s不支持Daemonset，也不支持一些与node相关的功能，这是由其实现的原理决定的限制。当我们观察到使用的K8s具有类似的功能限制时，我们有理由猜测这是一个运行在公有云平台的Serverless K8s。
当然，公有云托管的K8s集群与在私有云上安装维护一个K8s集群，两者对于基础设施工程师来说就完全不同了。在一篇名为《没人想要再管理 Kubernetes 了 ！》[1]的文章中一位工程技术高级副总裁提到：
有一点要弄清楚，托管Kubernetes很省力。它为我们运营，这点很重要，因为做到确保自己拥有运行[Kubernetes]所需的所有人并非易事。
安装管理公有云托管的可以明显节约所需要的人力与精力，这方面公有云平台对基础设施工程师来说具有明显的区分度。
最后假如我们允许工程团队直接与基础设施平台的API进行交互，并发现有大量的开源社区工具可以使用，例如Terraform、Pulumi、Crossplane等，那么我们可以立即确认所使用的是哪个公有云平台；私有云所能配套的开源工具链无论是在深度还是广度上都与公有云生态无法比拟。工具链生态也是公有云平台一个具有高度区分度的方面。
云计算平台的二象性
从以上的思想实验我们可以发现：
终端用户无法分辨，也不关心应用是否运行在云平台上。 从成本角度出发，公有云与自有数据中心的成本模式要体现出差异，完全取决于我们如何设计应用程序架构；我们使用到的动态弹性服务化的能力越多，越能在成本上发挥云的优势；反过来如果我们把旧有的自有数据中心的那一套原封不动地搬上云，是无法获得任何成本优势的，相反可能反而花费更甚。 站在工程团队的角度出发，我们对基础设施的使用方式会极大地影响到我们对云平台的感知能力，也就是说，抱着使用旧有的方式去设计架构与工作流，哪怕我们使用的的确是公有云，也与自有数据中心无异；要让云计算作为一种先进生产力真正提高和解放团队的生产效率，我们必须使用与传统自有数据中心时代迥异的架构、工具以及工作流。
云计算平台的首要目标用户应该是工程团队，特别是应用交付团队，因为工程团队更能把云平台用出区分度来；简单地把一个公有云交付到工程团队手上并不能直接提升云平台的区分度，错误的工作流一样导致我们把公有云用成传统裸金属集群。一个应用交付团队采用正确的工作流和工具链，可以极大加速向用户交付价值的迭代速度和频率，这种加速使得团队可以更频繁地调节自身，更好地适应各种新的变化。
云计算平台自从Iaas开始，为了降低从传统数据中心迁移上云的门槛，所以对传统应用架构和与运维工作流做了很好的兼容，这就使得我们可以在云平台上同时观察到各种不同的风格与模式，从适应自有数据中心的，完全由Iaas服务（虚拟机、负载均衡、块存储）组成的架构，到完全的SAM（Serverless Application Model）风格架构，可以同时存在并且互相交互。
但是这种公有云上的兼容传统架构的各种功能它们存在的目的应该也只是给予上云的企业一个快速迁移的缓冲，而不应该是企业用云的默认形态；正如人类的胚胎成长发育的过程中会有尾巴，但在随后的发育过程中，这个尾巴就应该被成长中的身体吸收；出生后的婴儿如果还保有尾巴，那是需要用手术来去除的。
云计算平台呈现出某种程度的二象性，我们使用它的方式决定了它在我们眼中所呈现的是传统的静态的一面更多一些，还是现代化的动态弹性的一面更多一些。对应用交付团队来说，需要直接与基础设施交互的能力，可以在需要的时候自助式地获取所需的各种基础设施，可以是通过API、SDK或是各种开源工具链。在设计软件架构时，工程团队越是努力地发扬其自动伸缩、按量弹性计费的特点，越是能够提升云平台对工程团队以及成本上的区分度。
云原生技术并非能够无条件提升云平台的区分度，使用不恰当的方式在公有云上使用例如K8s等云原生技术，与使用私有云无异（例如需要填工单或者邮件才能向生产环境部署K8s工作负载）。云原生平台并不等同于云平台，哪怕是设计面向云原生平台的应用时也要考虑如何结合目标云平台的特点，发扬其长处。
在工程团队与公有云基础设施的交互过程中，人工的因素越少，工具链的因素越多，云平台的区分度越高，越能体现云计算的优势。
参考资料
《没人想要再管理 Kubernetes 了 ！》: https://www.infoworld.com/article/3614850/no-one-wants-to-manage-kubernetes-anymore.html