云计算的革命尚未开始

sh 文件是操作系统的脚本代码文件，该 Slogan 意为避免在 IT 运维中使用 sh 脚本文件，首先由 Splunk 所提出

最近一位朋友在他的朋友圈发了这样一张 T 恤的图，并且怒喷某头部云平台的运维平台产品仍然提供了代码脚本分组管理功能，并且喜滋滋地将其作为一大功能大书特书的行为，将其斥为云计算的反动派，宣传腐朽落后的技术理念。没成想因为忘记说明是 T 云，结果惹来一众 A 云大佬的关注；由于对号入座的人太多，不得不郑重声明喷的是 T 云而非 A 云（A 云这种对号入座的心态也非常值得玩味）

我觉得这件事一下子勾动了心中这些年一些零零碎碎的想法。最近两年公有云领域的竞争情况是，中小玩家逐渐被挤出竞争，纷纷开始想在私有云方面寻找一线生机；而头部大厂似乎也放慢了对公有云市场的耕耘，也开始在私有云、智慧城市、地方政务云这些“大单”上发力，看起来公有云的增长与竞争格局似乎已经接近终局一般。打开公众号“云头条”，基本新闻都是某地的政务云教育云智慧城市云的招投标情况，都是多少台服务器，多少的显卡，多少套虚拟化管理系统，多少个数据库、消息队列等平台，云的竞争似乎变成了数据中心规模的竞争。

针对云的测评，无论是厂商还是第三方的，基本也都是着眼于性能测试，比的是 CPU 谁快，IOPS 谁高，集群规模谁大等等。

云真的变成了一个单纯竞争规模、尺寸、成本和性能的行业了吗？这就是我们想要的云计算革命吗？

我并不这样认为。

电气化的曲折道路

在这里我想要先介绍 BBC 的一篇文章：《Why didn't electricity immediately change manufacturing?》 ，以下是我的一点意会的译文：

1870 年托马斯爱迪生与约瑟夫斯旺两人分别独立发明了实用的灯泡，1881 年爱迪生在纽约和伦敦分别部署了直流电发电站，并且开始对外出售电力。一年以后，爱迪生有了第一个使用电力来带动机器进行生产制造的客户。

但是直到 1900 年，全美仍然只有不到 5%的工厂使用电力作为主要能源，大部分工厂坚持使用蒸汽机，这还是属于蒸汽机的时代。

以蒸汽机作为能源的工厂一般都有一个巨大的蒸汽机提供动力，同时通过一根非常长的，通常与厂房一样长的传动轴穿过整个厂房来分配动力。有时传动轴还会伸出厂房，进入其他厂房传输动力。

副轴、皮带以及齿轮环环相扣，驱动着工厂里的锤子、冲床、压床以及织布机，甚至可以通过垂直齿轮和轴，通过地板上的洞在楼层之间传输动力。这一切的动力机械被封装起来，以防止火灾通过缝隙蔓延开来。整套传动系统要持续地用大量润滑油持续润滑。

蒸汽机极少停机。只要工厂里有一部机器需要工作，那么蒸汽机就要保持运转，就要持续燃煤烧水。

这个由齿轮、传动轴、皮带搅动着润滑油、灰尘的复杂系统同时也是一个非常危险的机器，时不时就会有倒霉的工人因为袖子或者鞋带被绞住而被拖进这个无情而又吞噬一切的机器里。

有些工厂主尝试将蒸汽机替换成了电动机，使用附近发电站提供的更为清洁且现代化的电力驱动机器。但尽管付出了巨大的改造成本，这些工厂主大多数无法得到令人满意的收益。直到 1910 年，绝大多数的企业家虽然关注电力系统方面的进展，但仍然会选择老式的蒸汽机。

这是为什么？因为如果想要发挥出电气化的优势，工厂主需要一种全然不同以往的思维方式。他们当然可以直接把旧式工厂的蒸汽机直接替换成电动机，而其他部分不变，这使他们可以用最低的成本将工厂动力源替换成电力。

但问题是电动机实际上可以做的更多。电气化的关键在于可以把电力轻松传递到它所需要被使用的地方，并且可以弹性使用。不用机器时只需要关掉开关，就不会产生电力消耗。

小号的蒸汽机完全没有效率，它无法提供足够整个工厂使用的动力，但是小号的电动机却可以驱动一定数量的机器。所以新式工厂可以设置一系列的电动机，每一个电动机驱动一个小号传动轴。随着技术的发展，每个工作台都可以配备一个独立的小型电动机驱动自己的机器，动力的传输也由轴传动改为由电线传输电力。

旧式的蒸汽机厂房必须修建的足够坚固以承载巨大的钢制传动轴，而新式电气化工厂却可以修建的更加轻便与透气通风。

旧式的蒸汽机工厂在设计布局时必须围绕着传动轴来做设计，一切都是为了能够简单地获取动能；电气化意味着我们设计工厂时更多地考虑的是提升合作效率和生产力。

旧式的蒸汽机工厂昏暗且密不透风，所有的设备都围绕在传动轴和动力井周围；新式的电气化工厂可以自由展开，并且拥有更多的窗户，使得更多的阳光和新鲜空气可以进入厂房。

旧式的蒸汽机工厂里蒸汽机是核心；而在新式的电气化工厂，工人才是主角。

工厂从此变得更加整洁与安全，同时也更高效，因为机器需要运转时才打开开关运转，停机时关上开关，就不再消耗电力。

我们无法简单地把蒸汽机换成电动机而不动其余就能够获得这些进步，我们必须重新设计一切——从工厂的布局，到生产流程，都需要适应新的动力源。

同时由于工人的生产方式变得更加自治与弹性，我们也要改变招工、培训流程，甚至是薪酬体系也要做相应的改变。

面对这些改变，有些工厂主犹豫了。他们的犹豫是完全合理的。他们当然不想把自己既有的投资扔进垃圾堆，但也许他们只是需要更多时间去思考这样一个需要改变一切来适应这种新技术的全新世界对既有规则的冲击。

有赖于电力系统越来越廉价并且可靠，同时因为一系列限制欧洲移民的新法律的出台，美国工人成本变得更加昂贵，最终，电气化革命还是无可避免地发生了。

平均工资的飙升使得招聘员工越来越多地开始关注质量而非数量。训练有素的工人可以充分利用电气化给予他们的自治性，同时越来越多的工厂主学会了如何最大化电动机的优点，关于生产制造的新理念得到了大范围传播。

时间来到 1920 年，美国制造业的生产效率以一种前所未见的方式飙升。

我们可能将生产效率的大幅提升归功于某种新技术的的诞生，但其实并非如此，我们发现，有时这种进步会大幅晚于新技术的诞生，有时会晚 50 年。

译文到此结束。

直接迁移(Lift And Shift)——云计算领域的传动轴

早期推广企业上云时为了降低上云的难度，云厂商和企业有时会采用一种名为直接迁移(Lift And Shift)的策略。这种策略是指将应用程序以及其数据存储、操作系统和架构的精确副本从本地环境迁移到云端的过程。

直接迁移相对来说实施成本较低，风险较小，实施周期较短，作为企业上云的初始阶段具有明显的优势。但是将本地数据中心的应用原封不动地迁移到公有云上，就如同将旧式工厂的蒸汽机替换成了电动机而不动其余一样，并不能最大化云计算所带来的收益；有时企业经过核算之后甚至会发现，长期使用的场景下，公有云的服务器资源使用成本相比起自有机房内采购的服务器，不但没有降低，反而可能更高。

蒸汽机工厂简单地把蒸汽机替换成电动机并不能享受到电动机可以弹性工作的优势（可以随时开关机，关机时不消耗电力），简单地直接迁移应用上云也无法享受到云计算带来的弹性计算的优势。

甚至很多中国公有云厂商设计的定价模型对公有云的弹性特征都是不友好的。举一个例子，同样是包年包月的方式付费，AWS 采用的计费方式属于后付费方式，比如客户购买了一台 16 核 32G 内存的服务器一年的使用权限，那么在这一年的时间内客户可以随时开启这样一台 16 核 32G 的服务器，不会有额外费用。客户可以随时删除这台服务器，重新建立一个同尺寸的新服务器，可以安装不同的镜像，执行不同的计算任务，机器的 ID 可以不同，AWS 不管这些，只要是同一尺寸的机器，就不会有额外的费用。假如客户开了两台这样的机器呢？那么这个月的账单里会出现一台机器的按需使用实例的费用，另一台的费用已经被年付的预付费包括了。

同样的包年包月付费方式，国内大部分公有云都是要求客户提前付费，随后直接分配一台服务器实例给客户，这笔年费与这台服务器实例是绑定的。如果我们删除了这台服务器呢？那么会产生一个退费逻辑，会将这台服务器实例尚未使用的时间折算成费用退还到客户的账户内。那这种退费会带来什么样的后果呢？比如我年初年付购买了一台服务器，此时账户余额为 0，但我有了一台可以运行一年的服务器实例；年中的时候我删除了这台服务器，然后想重新创建一台同尺寸的服务器。我想以年付的价格继续使用半年到年底（这样我总共以年付的价格使用这样一台服务器一整年的时间），我会发现这是不行的，因为我的余额不足以让我再购买一年的时长，同时不买足一年的时长我就不能以年付的价格购买六个月。

更不要说有时云厂商会在某一天搞活动，在这一天可以以非常优惠的价格购买年付费的服务器实例，但如果购买的实例在日后被删除了，那么这个优惠也就随之而去了。

诸如此类的各种细节问题限制了我们对云的看法，我们仍然是以看待和管理自有数据中心的方式来对待公有云；购买的预留实例我们会紧紧地握在手中，这一切的阻碍都影响到我们进一步解放公有云的弹性和可编排能力。

目前有大量的企业对云的使用就如同把蒸汽机拆掉换成电动机，然后说：你看，我们成功上云了。

噢并非如此我的朋友，并非如此。

盲人摸象——割裂的云原生运动

为了使得更好地解放云的生产力，业界近年来开始提出云原生（Cloud Native）运动。云原生并不是某一种或几种具体的技术，而更多的是一种文化。根据云原生计算基金会（CNCF）的定义：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

经过数年的发展，云原生的生态圈有了爆炸式的发展，就像当年的大数据全景图（Big Data Landscape），现如今要完整加载云原生基金会的全景图也已经是一件比较缓慢的过程了，并且很难从全景图上快速找到一个目标项目的图标——如果 CNCF 基金会的目的是展示其生态的庞大和繁荣，那么 CNCF 全景图已经超额完成了这一目标。

CNCF 全景图——为了将图片大小缩至可以上传图床我缩小了图片大小，这使得从图中识别项目图标更得更加困难

然而在云原生时代，我们交付云端应用有没有变得更加简单和快速呢？目前看效果有限。

交付一个生产环境的云端应用需要考虑多少环节？我们要考虑业务逻辑、应用架构、服务发现、故障转移、服务可观测、安全控制、背压熔断与优雅降级服务网格、Dockerfile、镜像存储与版本化管理、安全扫描、K8s 容器编排与服务编排、各种排查故障的工具、脚本，日志系统等等等等。

一个简单的问题，我该如何从无到有地在目标环境中部署一个生产就绪的应用，并且确保它的维护与更新是可持续的？由于 CNCF 生态给了我们太多的选择与答案，而每个选择与答案又有它们所适用的范围与优劣势，再搭配以高速的发展和演进，我们很容易面临两种问题：

1. 分析瘫痪

2. NIH 综合症

分析瘫痪是指由于选择过多，我们无法获得足够多的信息使得我们有足够的信心做出具体的决策，导致我们总是在对比与分析，不敢付诸生产环境的实践。

NIH 综合症意为非我所创综合症（Not Invented Here），由于全面分析开源社区的所有选择与答案是不现实的，所以为了最大化地掌握自身的命运，往往会选择自研。我们经常会看到一些加拉帕戈斯式的工具、项目以及集群（一个典型的例子是遇到过一个团队选择在 AWS 上使用 Rancher 管理一组 EC2 虚拟机组建 K8s 集群，而非使用 EKS 集群，原因似乎也是为了“最大化的控制力”）。

使得问题变得更麻烦的是 CNCF 生态中的各个项目与厂商，大部分厂商会将自身的目标定位在 CNCF 划定的某一个具体的领域内——云原生网络、云原生存储、云原生数据库、云原生服务网格、服务网关、Serverless 运行时等等等等，他们会沉迷于对局部问题的深度优化。

然而云的使用者在旧式的思维指导下用云观念落后，导致局部优化对总体效率的提升相当有限，反而是增加了更多的复杂度。如今的云原生运动面临着盲人摸象式的困境，每个人对云原生到底哪个是重点都有着自己独特的理解和答案，而作为整体，理应带给我们更高生产力的那种新时代的云计算应用交付方式，仍然像是佛经中提到的林中象一般扑朔迷离，极少有人理解它是什么，它在哪里。

云计算革命的目标应该是人

云原生革命的目标应该是解放 IT 从业者的生产力，减少价值流动中的障碍，提升价值的交付速度和频率，应该是提升人的自治性，提升人的综合素质和效率。

目前阻碍技术团队最大化地发挥交付能力的最大障碍，并不是哪个局部细节没有最优化，而是作为整体，我们并没有一种适用于云原生时代的新的研发交付范式。

新的技术已经到来，而我们目前使用的范式仍然偏向旧有的，静态的、割裂的时代，我们就是在电动机驱动传动轴厂房中工作的工人、工厂主。生产关系不改变，工厂不重新设计，针对发电厂做再多的优化和改良对生产效率的提升都是有限的。蒸汽机时代的工人要从蒸汽机直接获取动力是十分困难的，更遑论要根据情况对自己的工作台进行个性化的改造；而目前技术团队要直接获取基础设施及服务也是十分困难（假如还要借助于电子邮件或者工单的话），进行个性化改造更是难上加难。

我们需要的是全新的工厂，全新的工人，全新的生产关系和工具链。我们需要的是认清这样一个事实：只有优化整体，彻底解放人的生产力才能带来总体收益的提升。

云计算革命仍然处于一阶状态

电气化与云计算有着许多的相似点。就比如云计算厂商口中一句高频率的口号，就是要把计算做成像水电这样的模式，用时打开龙头开关就可以获得，用完了关上就不再计费。

云原生运动帮助客户像使用水电一样使用云计算资源了吗？部分上是的，在许多具体的问题上我们的确获得了一些进展，但是作为整体而言还远远不足。比如直到现在，要编写一个可以多云部署，并且能够把目标云平台的各种优势发挥到极致的云端应用，对技术团队来说仍然是一件困难的工作。我们的从业人员仍然在各种由不同产品、不同服务、不同职能、不同部门和组织所构成的筒仓之间挣扎，价值的流动仍然受到各种各样的阻碍。

电气化革命带给云计算革命的启示是，至少在中国，云计算的革命远未结束，它甚至尚未开始。云计算理念的诞生到今天也不过短短十来年，我们的组织结构和社会文化尚未适应这种水电化的弹性，以及与微服务架构所适应的分布式、小规模自治团队的协作方式。

云计算革命在中国目前仍然处于一阶状态，也就是我们会把最终生产的系统部署在公有云或者私有云上交付给用户，但是我们本身的生产过程却没有充分利用云的特性。例如现在依然有不少团队的 CI Agent 不是使用 Serverless 容器，或者部署的 Artifact 仓库使用的存储不是例如 S3 这样的 Serverless 对象存储，即使公有云提供了各种简便快捷的服务，许多公司和团队仍然倾向于重复发明自己的加拉帕戈斯轮子。什么时候我们的生产过程本身也是大量使用到云的特性，复用成熟的公有云服务，那么云计算革命就算是进入了二阶状态。

那么有没有三阶状态呢？我想是有的。软件工程相较于其他的传统工程来说有一个显著的不同点，就是软件工程包含了对自身效率提升的工程实践，例如编写生成代码的代码，编写自动检查合规的工具等等，我们可以通过编写软件来提升我们编写软件的效率，这也就是元编程（Metaprogramming）思想的威力。同样的道理，我们也可以探索如何使用云计算的能力来提升我们使用云计算的能力，例如将复杂的云应用部署流程用基础设施即代码（IaC）技术进行封装后，将其封装为一个 SAM（Serverless Application Model）风格的云端应用，通过 API 暴露其能力，使得我们可以通过调用简单的自助服务来获得各种复杂的云端环境和能力。这种云计算的元编程应用本身又可以组成更高阶的云计算元编程服务。

回想电气化革命的过程，就是把动力和人的关系进行反转；传统的蒸汽机工厂之所以是这样设计的，是因为动力是难以获得的，所以工厂必须以蒸汽机和传动系统为核心，人从属于机器；而电气化时代，通过电线传递的电力是易于获得的，并且通过开关控制可以弹性获得电力，所以电气时代是以人为核心，机器从属于人。只有当人和动力、人和机器的从属关系进行了适当调整之后，电气化的高效率才能被完整释放出来。

同样的，云计算时代人和基础设施的关系也要进行调整。传统数据中心时代，基础设施是难以获得的，是昂贵的，所以人要从属于基础设施；云计算时代基础设施是易于获得的，是廉价的，是弹性的，所以基础设施要从属于人。只有每个人都能像拧开水龙头洗手那样方便地随时随地获取所需要的基础设施时，才能解放人的生产力，释放云计算真正的效率。