传统的软件交付模式（应用开发人员专注于软件开发，IT运维人员负责将软件部署到服务器上运行）已经不能满足互联网软件快速迭代的需求。于是，DevOps作为一种打破研发与运维之间隔阂、加快软件交付过程、提高软件交付质量的文化理念和最佳实践，逐渐流行起来。DevOps的现状DevOps的火爆得益于业界对应用软件敏捷开发和高质量交付的需求，因此为开发和运维开辟了一个“公共空间”，双方可以紧密合作.当时，软件研发还是一个新兴行业，人们习惯于向成熟的制造业学习。制造业解决大批量生产的方式是建立一条流水线，通过流水线将每一步的内容标准化，而流水线上的工人只需各司其职，快速熟练地完成自己的工作自己制作的部分内容。因此，DevOps借鉴了制造业的经验，开始构建持续集成/持续交付（CI/CD）流水线，催生了一系列自动化/半自动化工具（如puppet、chef、ansible等）.),结合脚本。拓展能力，将研发运维中的大量操作标准化，从而实现相互协作的目标。但最终，必须有人投资构建这些工具，于是DevOps团队出现了。DevOps团队搭建的工具和平台帮助研发更容易贴近生产环境，让研发在持续集成和持续交付的过程中一键部署，快速试错，从而很大程度上提前暴露软件，避免软件实际运行过程中出现的问题。DevOps本质上是为了运维。它通过自动化工具提供生产环境的运维流程，屏蔽基础设施细节，让软件本身的问题更容易暴露，让这些问题尽早交给研发解决。这些其实都是在帮助减轻运维的负担。这套模型一开始效果不错，但随着时间的推移，问题慢慢暴露出来。DevOps本身并没有给企业带来直接的利润，也没有增加产品的功能。他们是企业的成本中心，所以很多企业都不愿意在DevOps上投入太多的成本。久而久之，DevOps的能力无法匹配研发人员不断增长的需求，不愿意随着云和开源社区的发展而继续进化，反而成为软件研发的瓶颈。试想，有多少大公司的技术人员对自己公司的“研发效率”工具感到满意？云计算的普及聪明的企业总能从自身需求中找到行业共性需求。AWS就是这样诞生的。早在2006年，他们就率先将软件部署所需的网络、计算、存储等基础设施作为服务提供。对于用户来说，它允许任何人在不购买服务器等物理硬件的情况下构建互联网应用，规模使得整体成本低于用户自建。云计算IaaS、PaaS、SaaS的概念在那一年开始清晰起来。云计算早期，用户主要使用IaaS服务，如虚拟机、存储等，使用云计算服务的企业仍然需要运维来管理这类基础设施，只是运维管理的对象发生了转变从物理机到虚拟机。只是一台机器，没有本质区别。随着云计算的快速发展，云的能力也在不断得到补充和增强，逐渐将原本由运维提供的方方面面能力转变为云服务，其中自然包括管理软件全生命周期的方方面面。服务，从代码托管、持续集成、持续交付，到监控、告警、自动伸缩等能力，都可以在云端找到对应的服务。种类之多，数量之多，令人瞠目结舌。但DevOps仍然有一席之地。云连接的难度太大，涉及的云服务很多，不同云厂商提供的服务也不统一。为了使用云上的产品，我们不得不花费大量的时间去学习，同时为了防止绑定云厂商而不得不适配多个厂商，DevOps还是需要屏蔽实际环境的复杂性开发和过去一样，但是这次他们负责管理的基础设施变成了云资源。改变一切的KubernetesKubernetes的本质是现代应用基础设施，关注的是如何将应用与“??云”自然地结合起来，使“云”的价值最大化。Kubernetes强调基础设施可以更好地与应用程序协作，以更高效的方式为应用程序“交付”基础设施能力，而不是相反。在这个过程中，Kubernetes、Docker、Operator等曾在云原生生态中扮演过关键角色的开源项目，正在将应用管理和交付推向一个与以往完全不同的境地：Kubernetes用户只使用声明式的方式描述你的应用程序的最终状态是什么，然后一切就结束了。Kubernetes会处理所有其余的事情。这就是Kubernetes非常重视声明式API的原因。这样一来，Kubernetes自身接入的基础设施能力越强，Kubernetes用户可以声明的最终状态就越丰富，其职责也就越简单。现在，我们不仅可以通过Kubernetes声明应用程序的运行结束状态，例如；“本应用需要10个实例”，我们还可以声明应用的很多运行结束状态，比如：“本应用升级中”，“当其CPU使用率大于50%时，请自动扩容2个实例”。这对传统的DevOps工具和团队提出了挑战：如果业务研发只需要通过声明式API声明其应用程序的所有最终状态甚至完成SLA，其他一切都将由Kubernetes自动处理。那么他有什么理由要连接学习各种DevOps流水线呢？也就是说，长期以来，DevOps实际上充当了研发和基础设施之间的一层“胶水”。而现在，Kubernetes正通过其强大的声明式API和无限访问应用程序基础设施的能力，完美地扮演着这个“胶水层”的角色。这也提醒我们，最后一个受到Kubernetes系统强烈挑战的“胶水层”其实叫做“传统中间件”：它正在遭受ServiceMesh的巨大冲击。DevOps会消失吗？近年来，Kubernetes项目经常被描述为DevOps的“最佳搭档”。类似的观点是，Kubernetes和Docker一样，解决的是软件运行时的问题。这意味着Kubernetes更像是一个“时髦”的IaaS，只是运行时从虚拟机变成了容器。因此，只要现有的DevOps思想和流程能够与Kubernetes对接，就可以享受到容器技术带来的轻量级和灵活性。对于崇尚“敏捷”的DevOps来说，这显然是最佳组合。不过，至少目前来看，Kubernetes的发展路径并不是IaaS类角色。虽然它专注于接入底层基础设施能力，但它本身并不是基础设施能力的提供者。而且，相比软件运行时，Kubernetes似乎更关心软件的生命周期和状态流。不仅如此，它还提供了一种称为“控制器模型”的机制，不断逼近软件的实际状态和预期状态，这显然超出了“软件运行时”的范畴。Kubernetes项目对应用本身的“额外关注”，使其与类IaaS的基础设施明显区分开来，也使其“胶水”定位更加明显。如果Kubernetes足够强大，DevOps是否仍然有必要作为研发和基础设施之间现有的“胶水层”？在所谓的云原生时代，应用研发和交付真的会走向“一个声明”，然后“放手”，让DevOps彻底消失吗？然而，至少就目前而言，Kubernetes项目距离这个愿景还很远，还有很多困难需要克服。“PlatformforPlatform”API的局限性Kubernetes是一个典型的“PlatformforPlatform”项目，其API离纯研发的角度还很远。比如一个Deployment对象，不仅包括研发端关心的镜像，还包括基础设施端的资源配置，甚至容器安全配置。另外，KubernetesAPI并没有提供描述和定义“运维能力”的方式，这也导致声明后无法“放手”。这也是为什么目前还需要DevOps的原因：Kubernetes的大部分领域还是要通过研发和运维的协同过程来填补。无法描述更多的云资源。K8s的原生API只包含一小部分云资源。比如用PV/PVC来表示存储，用Ingress来表示负载均衡。但是，这对于完全声明性的应用程序描述来说还不够完全不够。比如研发希望在K8s上找一个概念来表达数据库、VPC、消息队列等需求时，会很迷茫。然而，现有的解决方案都完全依赖于云厂商的实现，这就带来了新厂商锁定的困惑。Operator系统缺乏互操作性Kubernetes的Operator机制是项目能力可以无限增长的公开秘密。但遗憾的是，目前所有Operator之间的关系就像一个接一个的烟囱，彼此没有任何互动和协作的可能。比如我们通过CRD和Operator将云端的RDS扩展到K8s声明式API体系，但是当第三方想写一个定时备份RDS持久化文件的CRDOperator来配合时，往往无从下手。这又需要DevOps系统的介入来解决问题。未来？显然，目前的Kubernetes项目还是需要依托DevOps体系才能真正完成软件的高效迭代和交付。这是无法避免的：虽然Kubernetes自称是一个“以应用为中心”的基础设施，但作为一个源自GoogleBorg的系统级项目，其自身的设计和工作层面还是更多地在基础设施领域。.但另一方面，我们也不能否认，Kubernetes在其关键路径上始终保持着研发端对“NoOps”的追求。这种愿望从提出“声明式应用管理”理论的第一天起就“显而易见”，而CRD和Operator体系的建立也终于让这种应用层面的关注有了落地的机会。我们已经看到许多DevOps流程“下沉”到Kubernetes中的声明性对象和控制循环中，例如TektonCD项目。如果Kubernetes的未来是100%声明式的应用管理，那么我们有理由相信DevOps最终会从技术领域消失，完全蜕变成一种文化。毕竟那个时候的运维工程师可能都会成为KubernetesController/Operator的编写者或者设计者。那么研发呢？他们甚至可能不知道Kubernetes曾经如此显赫。OAM2019年10月，阿里云与微软联合发布了开放应用模型（OAM），打破了传统的软件交付模式。OAM是一个专注于描述应用生命周期的标准规范，可以帮助应用开发者、应用运维人员和基础设施运维团队更好地协作。点击查看：OAM项目源码
