作者：「兜」，10年+运维从业经验

云原生，全新运维模式，其不亚于核弹一样的威力，自打诞生那一刻即震惊了整个行业的运维从业人员。云原生是什么？如何掌握云原生？云原生后，运维将何去何从？等等问题，尤如重棒当头。这一次，运维感觉到了危机……

本文，我们将围绕如上主题求同存异，分享我的一些思考。

细想来，突然发现公司全面拥抱K8S已经2年有余，最近1、3、5年规划也将云原生、Server Less、Server Mesh做了更体系长远规划。与此同时，我们也不断反思如下几个问题：

究竟什么是云原生！？公司当下算云原生了吗？
云原生究竟为公司带来了哪些收益？又解决了哪些问题？
云原生庞大的技术架构体系下，我们该如何技术选型？又该将云原生进行到何种程度才算结束？
云原生后，运维又将该何去何从？

01

究竟什么是云原生！？公司当下算云原生了吗？

云原生| Tallon

究竟什么是云原生？

不同企业对于云原生有不同的解释，当前在业界具有广泛影响力的云原生计算基金会（Cloud Native Computing Foundation, CNCF）认为: 云原生是一类技术的统称，通过云原生技术，我们可以构建出更易于弹性扩展的应用程序。

这些应用可以被运行在不同的环境当中，比如说：私有云、公有云、混合云、还有多云的场景。云原生技术包括：

容器
微服务
服务网格
Serverless
DevOps
API管理
不可变基础架构等

通过云原生技术构建出来的应用程序，称之为云原生应用，底层基础架构的耦合比较轻，因此易于迁移，它可以充分地利用云所提供的能力，因此云原生应用的开发、部署、管理相对于传统的应用程序更加高效和便捷。

而阿里ACP(阿里云云原生容器工程师)则给出了更为严格的定义：从云中来，从云中云，即应用的完整生命周期都在云上。

金融体制，早期是混合云架构，K8S后，AIC(All In Cloud)，使用的技术栈包括但不限：容器、微服务、DevOps。

**如是看，我们公司也算是云原生用户了。**云原生不仅限如上技术，CNCF官方给出完整的技术图谱！

CNCF技术图谱2021-11-04（来源：CNCF官网，文末可下载高清大图）

1.1、云原生技术图谱概要分析

乍一看，云原生技术图谱涉及技术繁杂，数百种之多。其实拉远观察后会发现，图谱做了技术分类，核心技术架构分为：

供应层（Provisioning）
运行时层（Runtime）
编排和管理层（Orchestration and Management）
应用定义和开发层（Application Definition and Developement)

1.2、供应层（Provisioning）

供应指的是为云原生应用准备标准基础环境所涉及的工具。它包含了基础设施的创建、管理、配置流程的自动化，以及容器镜像的扫描、签名和存储等。供应层通过提供设置和实施策略，在应用程序和平台中构建身份验证和授权，以及处理密钥分发等等的工具，也拓展到了安全领域。

供应层包括：

自动化和部署工具
容器注册表
不同安全领域的安全和合规框架

1.3、运行时层（Runtime）

接下来是运行时层。这个词可能会让你感到迷惑。像很多 IT 术语一样，运行时没有严格的定义，且可以根据语境有不同的用法。狭义上讲，运行时是特定机器上准备运行应用程序的沙盒——也就是保障应用程序正常运行所需的最低配置。广义上讲，运行时是运行一个应用程序所需的所有工具。

在 CNCF 云原生全景图中，运行时保障了容器化应用程序组件的运行和通信，包括：

云原生存储
容器运行时
云网络

1.4、编排和管理层（Orchestration and Management）

一旦按照安全和合规性标准（供应层）自动化基础设施供应，并安装了应用程序运行所需的工具（运行时层），工程师就需要弄清楚如何编排和管理应用程序。编排和管理层将所有容器化服务（应用程序组件）作为一个群组管理。这些容器化服务需要相互识别和通信，并需要进行协调。这一层可为云原生应用提供自动化和弹性能力，使云原生应用天然具有可扩展性。

这一层包含：

编排和调度
协调和服务发现
远程进程调用（RPC）
服务代理：服务间通信的中介。服务代理的唯一目的就是对服务之间的通信进行更多控制，而不会对通信本身添加任何内容。服务代理对下面将提到的服务网格（Service Mesh）至关重要。
API 网关
Service Mesh：某种程度上类似于 API 网关，它是应用程序进行通信的专用基础架构层，提供基于策略的内部服务间通信。此外，它还可能包含流量加密、服务发现、应用程序监控等内容。

1.5、应用定义和开发层（Application Definition and Developement)

现在，我们来到了最顶层。应用定义和开发层，顾名思义，聚集了让工程师构建和运行应用程序的工具。上述所有内容都是关于构建可靠、安全的环境，以及提供全部所需的应用程序依赖。

这一层包括：

数据库
流和消息传递
应用程序定义和镜像构建
持续集成和持续交付（CI/CD）

这里，我们不做赘述，更详尽内容可参考官方文档。

02

云原生究竟为我们带来了哪些收益？又解决了哪些问题？

作为运维，潜意识的第一收益是成本！但其实不然，如下问题会导致成本无法估算或成本优势延后：

长尾业务无法云原生或进度缓慢，导致冗余资源长时间无法释放，冗余成本并行运行时间很长，优势不明显；
云原生人力成本高昂，市场价平均高于5K不止；
云产品带来便利性的同时，B端商家模块化、消息消费类收费模式，C端用户只开不关，只增不减，只上不下等恶劣行为习惯，非常容易导致预算超标。

总结：成本收益不高。

2.1、收益

运维提效（图片来源于网络）

目前为止，我们真正最大的收益是SLA和隐性效能提升。云原生和微服务简直就是天作之合，微服务向云原生切换几乎可以完全平滑切换。做过云原生才会知道这个事情有多妙。简单总结收益如下：

微服务应用切换云原生，效果卓绝，技术成本可控，真正意义上实现了 Wrhite once, Run everywhere! 整个过程几乎可以实现平滑容器化。部分老业务涉及硬代码改造，会有一定难度。
隐性推动公司技术栈统一。金融企业&中大型项目&业务生命周期&业务类型等多重因素结合，Java是王者，Python，c++，go等诸多技术栈，在公司主流核心业务中均逐步淡化去除。
几乎可以实现无脑横纵向扩缩容。云原生去IP化后，推动各业务之间的权限管控颗粒度从细到粗的反向发展，为自动扩容铺平道路。推进金融化和互联网化基因的更深一步融合。
在云原生技术框架和标准规范下，新业务上线也完全标准化，一站式。SLA从天到分钟级别的提升，巨额收益。

2.2、云原生解决了哪些问题？

云原生意义重大，不夸张的讲，是迄今为止运维行业功能最强大的”软件”，更是颠覆性的运维产品「其实是系统，这里称之为软件方便大家理解」。

但与此同时，也为运维带来了极为夸张的行业属性提升，将运维的职业属性再次提升一个维度，行业聚集度也更高，从原来的纵向多面手转身为横向平面多面手，真正意义不再需要关注IAAS，不再需要关注PAAS的阶段也不会太远了。

所以，云原生最重要的意义不是解决了哪些问题，而是带来了哪些问题其实更重要！

我认为，云原生最少解决了下面这些问题：

运维技术栈不统一，新生代技术携带迅猛，技术行业技术内卷的事实；
重新定义经验的价值：从技术工具使用熟练程度变为云原生技术门槛大山是否翻的过去；
旧运维体系下，运维SLA经验依赖的事实；
真正意义上解决了，运维环境异构不一致的问题。

云原生带来了下面这些问题：

云原生技术门槛较高，淘汰一批学习能力差或不愿意接受新事务的从业人员，你可能不是其中一员，但下一条难逃；
云原生技术不仅提升行业门槛，还优化了行业人员配比。云化+K8S, 需要的运维人员更少，行业缩编，想想早期的IAAS从业人员，可以想像到云原生普及后的运维生存环境；
云原生后，对运维的要求不再是使用的熟练程度，而是产品化能力+运营能力+技术能力的多维一面能力。

03

云原生庞大的技术架构体系下，我们该如何技术选型？又该将云原生进行到何种程度才算结束？

云原生庞大的技术架构体系下，模块近300种，同质功能的产品也种类繁多，选型不再是容易的事情「虽然绝大多数的公司几乎不做技术选型」。关于技术选型，我先抛一个亲身履历的经典错误技术选型案例，你也许会觉得不可思议。

早在2017年，我们计划对新业务容器化，在Mesos，swarm和k8s 之间做决择。彼时，k8s已经凭借生态优势，各大主流容器技术厂商均声明兼容k8s，但我们在做完技术调研后，最终选择了 Mesos，后面的结果大家想像的到，不久前我们将Mesos技术栈剔除运维技术体系。

原因这里不做深究了，这里想表达的是：即使答案就在眼前，我们也有选错的时候。

技术选型的艺术（图片来源于网络）

3.1、关于如何技术选型

如何利用数据驱动产品形成闭环

浅显分享如下几点：

3.1.1、项目因素

项目需求类型、时间、规模、性质是影响技术选型的首要条件。时间是决定项目质量的不二因素，临时决定做的产品，初期一定问题爆炸多。

以诺豆公司为例，初期为了快速满足SAAS厂商入驻，我们为每个厂商提供一整套完整隔离的全套服务，每套成本百万级，明显亏本，但后期改造的产品是逻辑隔离。而出现该问题的原因就是临时接到的需求。

再比如hr系统，oa系统，crm系统，多数公司也会选择购买供应商的成熟产品，不会选择自己做。但这也属于技术选型的范畴。

3.1.2、团队因素

每家公司的技术栈不一样，像bilibili、ucloud是以go语言栈为主流，早期的豆瓣、知乎是以python为流技术语言栈，后期转为go。游戏公司的主流技术栈是c，c++。金融企业的主流技术栈是Java。

拥有显著特色的团队技术栈，技术选型也会有明显的技术亲和性倾向。

除了文化影响，人的影响巨大，前面造成的错误选型其实就是做技术选型的人。

3.1.3、技术因素

技术因素是构成技术选型的首要因素：

灵活性
扩展性
健壮性
性能
可维护性
社区活跃度
架构匹配度

等都是技术选型要考虑的因素。像k8s，mesos，swarm早期竞争阶段，如果趋势不明显，不如卧倒，少动多看。只有大公司才有试错成本。

云原生进行到什么程度才算结束？

技术演变通常是由业务驱动，而非技术驱动。

综上，云原生进行到什么程度才算结束，反倒变成一个简单的问题。诺豆公司接受容器化，也并非是技术驱动演变到容器化的阶段。前期运维为了接触到云原生这类新技术做过多种尝试，但最终都被老板PASS.而最后推动公司云原生的，也是CTO级别的变动，自上而下的技术演变。

当下我们正在做的1,3,5年规划，期望把多云、多活、Server Mesh、Server Less提到规划议程中，是否审核通过，最终也要看老板的意愿，需要老板在收益和投入，以及公司战略重心之间做评估！而像拍拍贷，则使用是混合云的方式，使用混合云的要因也并非技术驱动，也并非科技创新需要，而是业务早期遗留的巨额硬件资产和云原生之间不能很好的规划成本。

技术人的思维永远是要最新的。但只有摆脱纯技术人思维，才能走出「云原生后，运维将何去何从的困境」..

04

云原生后，运维又将该何去何从？

原生后期，运维未来何去何从，个人观点如下：

不会消失，但会严重缩水
2B背景下运维的求生域
云原生不是解药，SRE也不是银弹
行业特质残存死水

上帝掷骰子吗（图片来源网络）

4.1、不会消失，但会严重缩水

先说结论，不一定对，但观点明确！运维行业不会消失，但市场容量会逐年缩水。现在IAAS运维的命运，就是未来PAAS运维的命运。

核因如下：

技能培训行业不景气，生死边缘徘徊；运维培训，校招人数在逐年下滑，社招转型居多数；
高等院校招生方向，由原来普通计算机网络、软工向智能 AI、大数据方向改变；
2B行业强势下沉，挤压PAAS运维生存空间，运维成长土壤更加贫瘠；
企业招人要求逐年提高，且趋势日渐明显，逐步走向高、精、尖、专要求，市场两极分化；
人力成本逐年高昂，公有云让普通中低级运维外包成为可能，且少数巨头公司已经开始实践。

4.2、2B背景下运维的求生域

社交、娱乐、电商、游戏、金融、门户等C端日常所需均已被寡头侵蚀瓜分，普通C端客户所能分配的时间再无多余，这也意味着没有潜力可挖。这是各巨头冲击2B服务市场核因。

公有云IAAS革命了网络、IDC运维的命，公有云PAAS日趋完善后，靠纯IDC资源流量性质的公司，再无大树可寄生，巨头大包大揽，没有技术核心只有死路一条。同时，PAAS运维的命运未来大概率是IAAS运维的命运一样！

行业逐步成本导向，新岗位要求将重点考核公有云产品使用熟练程度，侧面引导运维技术方向。屁股决定脑袋，市场岗位属性再次强化为非技术引导，而由成本引导。

云原生逐步成为新型公司技术标准，但公有云包装完底层技术复杂实现，甚至ServerLess方式。运维成长土壤逐年流失，未来不会存在中级运维，两极分化更加极端。如前文所述，公有云让普通中低级运维外包成为可能。这意味着，廉价外包类低级廉价劳动力不再是开发特权，运维领域也会逐步出现。

4.3、云原生不是解药，SRE也不是银弹

如上文所述，云原生即解放了运维，也解放了老板。高并发、高性能、弹性扩缩容不再是行业难题，级别技术门槛被打破，运维行业将再次回到考验工具熟练度、行业深度、架构能力上。

即，云原生对行业是福利，小到个人是把双刃剑。

同步带来冲击的还有SRE运维。SRE运维本质是建立标准规范，并产品化落地。解决企业实际运行遇到的困、难、乱点，推进企业高效良性运转。云原生自带的行业解决方案能解决绝大多数规范性问题，公有云配套产品只需简单配置即可完成运维原来可能量变到质变才能完成的工作。

云原生后，服务治理功能还有待完善加强。SRE领域也在被侵蚀。

4.4、行业特质残存死水

如游戏、金融、证券、银行等行业物质很强的工种，运维还有较长时间腾挪，但也是最后的死水。

游戏分模块，也逐步支持容器化，甚至全模块支持容器化。

金融、证券、银行等金融核心业务、除部分敏感、核心业务需自建机房，未来最多也只是混合云架构，公有云占大头。