架构|云原生三问,剖析它的前世今生

2013年,一位来自著名PaaS云服务公司Pivotal的程序员Matt Stine提出“CloudNative”概念,云原生这个小众且深刻的名字从此流传开来。
经过两年的积累,2015年云原生计算基金会(CNCF)成立。这个由Google等大公司牵头成立的厂商中立基金会,在云原生应用推广普及方面起到不可或缺的作用。随着云原生概念不断演进,整个云计算市场对它关注度逐渐提升。
业内普遍认为2020年应被看作云原生的元年,大量云服务厂商对外声称可以对企业进行云原生应用的迭代更新,从而实现云平台设施弹性伸缩、动态调度、优化资源利用率等优势,然而事实真的如此吗?
感性来看,云原生是基于“未来的软件一定生长于云上”这一理念,对未来云平台发展路径提出的美好畅想。但是作为产业观察者,我们需要进行一系列问题的思考。首先是云原生到底应该被定义为一项技术,还是一种方法论抑或是多项技术总和的体系?其次云原生改革更新背后的动力和原因具体是什么?而我们应该如何去对现有的云平台进行云原生化布局?最后是否涉及具体赛道布局云原生的优先级顺序?在思考这些问题之前,我们可以回溯历史长河中技术革新事件,用来和当下云原生的火热市场情况进行类比。
回到1866年的德国,西门子制成发电机。实际可用的发电机在19世纪七十年代问世,这标志着电能转为机械能已成为现实,电力可以被用来带动机器,成为补充或取代蒸汽动力的“新能源”。有趣的是直到1900年,全美仍然只有不到5%的工厂使用电力作为主要能源,坚持使用蒸汽能源和配套设备成为业内常态。对于工厂来说,电气时代的开始依旧属于蒸汽时代。
与当下现代化工厂截然不同,当时以蒸汽机为主的工厂,所有的动力传输都依靠一根长度超过厂房的巨大传动轴实现。传动轴系统除分配动力的主轴外,副轴、皮带和齿轮的协同作用不可或缺,此外锤子、冲床、压床等设备相互配合才能完成动力系统的整体组成。
这样一种高度耦合化的系统造成了只要有一台设备需要运行,作为动力源头的蒸汽机就不能停下的窘境。同时复杂系统带来的是使用成本提高和危险性增加,由于遇险时蒸汽机无法及时停下,19世纪后叶丧生于工厂制造流程的工人不计其数。
在这样的内因外压下,小部分工厂注意到市场上存在更加清洁和现代化的电气机器。他们付出高额置换成本后,将蒸汽机换成电动机,然而令人遗憾的是,这并没有带来相对应的收益。因此绝大多数工厂依然坚持使用蒸汽机,这也造就了之前提到1900年“电气时代中的蒸汽时代”这一情况。
【 架构|云原生三问,剖析它的前世今生】究其原因,想要发挥电动机的全部优势,单单把原来的蒸汽机替换为电动机是远远不够的。电气时代要求工厂转换运营的思维模式,在蒸汽时代中人服务于机器,只要机器运行状态良好,工人的资质技术以及数量都对产出效率影响有限。电气时代恰恰相反,电气化设备允许工厂将视线从围绕传动轴的动力系统,逐渐转向工人工作效率和合作能力的提升。蒸汽时代中,动力源泉蒸汽机和巨大传动轴是核心;而在新式的电气工厂中,优秀工人才是核心。
我们时常会将生产效率或幸福程度的巨大提升归功于新技术的生产应用,但历史结论反复验证——真正的进步常常晚于新技术的诞生。我们需要更长的时间去思考这样的新技术对既有规则的冲击与影响。如何在信息乱流中找到真正改革的价值所在,是达到并超过预期的基础条件。
回到云原生的讨论上,早期“云”这个概念吸引了大量来自学术界、企业的视线。为了降低企业上云的难度,使上云流程标准化,云服务厂商通常会采用直接迁移(Lift and Shift)的方式。这种方式实施成本低、风险小、流程短,为早期上云策略提供了发展的基础环境。将本地数据的精准副本搬运上云的底层逻辑就如同一百多年前电动机替代蒸汽机的复刻。