Kubernetes 会不会“杀死” DevOps？

Kubernetes 会不会“杀死” DevOps？

作者丨孙健波（天元）  阿里巴巴技术专家

导读：DevOps 这个概念最早是在 2007 年提出的，那时云计算基础设施的概念也才刚刚提出没多久，而随着互联网的逐渐普及，应用软件的需求爆发式增长，软件开发的理念也逐渐从瀑布模型（waterfall）转向敏捷开发（agile）。

传统的软件交付模式（应用开发人员专注于软件开发、IT 运维人员负责将软件部署到服务器运行），再也无法满足互联网软件快速迭代的需求。于是，DevOps 作为一种打破研发和运维之间隔阂、加快软件交付流程、提高软件交付质量的文化理念和最佳实践逐渐普及至今。

DevOps 的现状

DevOps 的流行得益于业界对于应用软件敏捷开发、高质量交付的诉求，所以为开发和运维开辟了一块“公共的空间”，让双方可以在这里紧密合作。那时软件研发依旧属于一个新兴行业，人们习惯于向成熟的制造业学习，制造业解决大规模生产的方式，就是构建流水线，通过流水线规范化每个步骤对接的内容，而流水线上的工人们则只需要各司其职，快速熟练的完成自己这部分生产内容。

所以，DevOps 借鉴了制造业的经验，开始构建持续集成/持续交付（CI/CD）的流水线，催生出了一系列自动化/半自动化工具（如puppet、chef、ansible等），结合编写脚本的可扩展能力，将研发和运维的大量操作规范化，从而达到彼此协作的目标。但是最终还是要有人投入到这些工具的构建中，于是就出现了 DevOps 团队。DevOps 团队构建的工具和平台，帮助研发更容易地接近生产环境，让研发在持续集成、持续交付的过程中可以一键部署、快速试错，从而很大程度提前暴露和避免了软件在实际运行过程中的问题。

从本质上讲，DevOps是为运维服务的。它把生产环境的运维流程通过自动化的工具提供出来了，屏蔽了基础设施细节，同时让软件本身的问题更容易暴露，从而把这些问题尽量提前交给研发去解决。这些，其实都是在帮助运维减轻负担。

这一套模式在一开始运转良好，但是问题也随着时间的推移慢慢暴露出来了。DevOps 本身不为企业带来直接的利润，也不增加产品的功能，它们是企业的成本中心，所以许多企业不愿意为 DevOps 投入太多的成本。久而久之，DevOps 的能力便无法与研发人员增长的需求所匹配，不愿意继续伴随着云和开源社区的发展向前演进，反而成为软件研发的瓶颈。试想一下，有多少大公司的技术人员，对自己公司里的“研发效能”工具表示满意呢？

云计算的普及

聪明的企业总能从自己的需求中发现业界共有的需求，AWS 便是这么诞生的，他们早在 2006 年便首次把软件部署需要的网络、计算、存储等基础设施当做服务提供给用户，允许任何人在不购买服务器等物理硬件的情况下构建互联网应用程序，规模化使得整体的成本比用户自建更低。而云计算IaaS、PaaS、SaaS的概念也正是在那一年开始逐渐清晰的。

云计算的初期，用户主要使用的是IaaS服务，如虚拟机、存储等，使用云计算服务的企业依旧需要运维来管理这一类基础设施，只是运维管理的对象从物理机切换到虚拟机而已，并没有太本质的区别。

而随着云计算的快速发展，云的能力不断补充、增强，渐渐将原先由运维提供的方方面面的能力都转换成为了云上的服务，这其中自然包含了管理软件完整生命周期的各类服务，从代码管理、持续集成、持续交付，到监控、报警、自动扩缩容等一系列的能力，均能在云上找到对应的服务。品类之多、数量之巨，令人瞠目结舌。

但是 DevOps 依然有着用武之地。云的对接难度实在太大了，涉及到的云服务又多，不同云厂商提供的服务还不统一，为了使用云上的产品不得不投入大量的时间学习，而为了防止云厂商的绑定又不得不做多厂商的适配，DevOps 依旧需要像过去一样为开发屏蔽实际环境的复杂性，只不过这次他们要负责管理的基础设施变成了云资源。

改变一切的 Kubernetes

DevOps 会消失吗？

近几年，Kubernetes 项目经常被描述成 DevOps 的“最佳拍档”。类似的观点认为， Kubernetes 跟 Docker 一样，解决的是软件运行时的问题。这意味着 Kubernetes 更像一种“时髦”的 IaaS，只不过运行时从虚拟机变成了容器。所以，只要能够将现有 DevOps 思想和流程对接到 Kubernetes 上来，就可以享受到容器技术带来的轻量级与弹性。这对于提倡“敏捷”的 DevOps 来说，显然是最好的组合。

不过，至少目前看来，Kubernetes 的发展路径并不是一个类 IaaS 的角色。它虽然关注接入底层的基础设施能力，但它本身却又不是基础设施能力的提供方。而且，相比于软件运行时，Kubernetes 似乎更关心软件的生命周期和状态流转。不仅如此，它还提供了一种叫做“控制器模型”的机制来将软件的实际状态与期望状态不断逼近，这显然都已经超出了一个“软件运行时”的范畴。

不过，至少目前看来，Kubernetes 项目距离这个愿景，还有不少困难需要克服。

“Platform for Platform” API 的局限性

无法对更多的云资源进行描述

Operator 体系缺乏互操作性

未来？

OAM

在 2019 年 10 月，阿里云联合微软一起发布了开放应用模型 Open Application Model(OAM)，打破了传统的软件交付模式，OAM 是专注于描述应用生命周期的标准规范，可以帮助应用开发者、应用运维人员和基础架构运维团队更好地进行协同。

目前，OAM 还处于一个早期阶段，阿里巴巴团队正在上游贡献和维护这套技术，如果大家有什么问题或者反馈，也非常欢迎与我们在上游或者钉钉联系。

参与方式：

期待大家的参与！

云原生技术公开课

本课程是由 CNCF 官方与阿里巴巴强强联合，共同推出的以“云原生技术体系”为核心、以“技术解读”和“实践落地”并重的系列技术公开课。

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术圈。”

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。