【云原生】传统DevOps和云原生DevOps有什么区别？

参考：《PaaS DevOps 微服务》、阿里云原生

云原生的四大基石大家都应该知道吧，就是容器、微服务、持续交付、DevOps

其实博主公司的一些应用就是部署到K8S上，基本上用到了云原生相关的技术，之前和公司同事聊过一波，感觉就是概念和理解大于技术相关，能落地的相关技术主要就是容器和微服务这方面，如果是做后端开发的兄弟萌，微服务这方面应该没什么问题，容器这方面比较流行的就是Docker、K8S，上手应该不难（PS：公司运维同事两周精通K8S，直呼内行）

我们不聊技术，来聊一聊DevOps的发展，传统DevOps和云原生DevOps有什么区别？

DevOps中的Dev指的是Development（开发），Ops指的是Operations（运维），用一句话来说，DevOps就是打通开发运维的壁垒，实现开发运维一体化。

谈到DevOps的发展史，我们需要先谈一下敏捷开发。

敏捷开发是面向软件的，而软件依赖于计算硬件。我们知道，世界上第一台计算机是在1946年出现的，因此，软件开发相对于人类历史而言，时间并不长。相对于软件开发而言，人们更擅长工程学，如盖楼、造桥等。为了推动软件开发，1968年，人们将工程学的方法应用到软件领域，由此产生了软件工程。

软件工程的方式有其优点，但也带来了不少问题。最关键的一点是软件不同于工程。通过工程学建造的大桥、高楼在竣工后，人们通常不会对大桥或高楼的主体有大量使用需求的变更；但软件却不同，对于面向最终用户的软件，人们对于软件功能的需求是不断变化的。

在瀑布式开发模式下，当客户需求发生变化时，软件厂商需要修改软件，这将会使企业的竞争力大幅下降。

传统的软件开发流程是：

产品经理收集一线业务部门和客户的需求，这些需求可能是新功能需求，也可能是对产品现有功能做变更的需求；

然后进行评估、分析，将这些需求制定为产品的路线图，并且分配相应的资源进行相关工作；

接下来，产品经理将需求输出给开发部门，开发工程师写代码；

写好以后，就由不同部门的人员进行后续的代码构建、质量检验、集成测试、用户验收测试，最后交给生产部门。

这样带来的问题是开发周期比较长，并且如果有任何变更，都要重新走一遍开发流程。在商场如战场的今天，软件一个版本推迟发布，可能到发布时这个版本在市场上就已经过时了；而竞争对手很可能由于在新软件发布上快了一步，而迅速抢占客户和市场。

正是由于商业环境的压力，软件厂商需要改进开发方式。

2001年年初，在美国犹他州滑雪胜地雪鸟城（Snowbird），17位专家聚集在一起，概括了一些可以让软件开发团队更具有快速工作、适应变化能力的价值观，制定并签署了软件行业历史上最重要的文件之一 ——敏捷宣言。

敏捷宣言中的主要价值观如下：

个体和互动高于流程和文档。

工作的软件高于详尽的文档。

客户合作高于合同谈判。

响应变化高于遵循计划。

有了敏捷宣言和敏捷开发价值观，后续产生了对应的开发流派。主要的敏捷开发流派有极限编程（XP）、Scrum、水晶方法等。至此，敏捷开发有理念、有方法、有实践。随着云计算概念的兴起以及云计算的不断落地，敏捷开发也实现了工具化。

既然谈到了敏捷开发，那么敏捷开发和DevOps有什么关系呢？敏捷开发是开发领域里的概念，以敏捷开发阶段为基础，有如下阶段：

敏捷开发→持续集成→持续交付→持续部署→DevOps

从敏捷开发到DevOps，前一个阶段都是后一个阶段的基础；随着阶段的推进，每个阶段的概念覆盖的流程越来越多；最终DevOps涵盖了整个开发和运维阶段。正是由于每个阶段涉及的范围不同，因此每个概念所提供的工具也是不一样的。

持续集成（Continuous Integration）：代码集成到主干之前，必须全部通过自动化测试；只要有一个测试用例失败，就不能集成。持续集成要实现的目标是在保持高质量的基础上让产品可以快速迭代。

持续交付（Continuous Delivery）：开发人员频繁地将软件的新版本交付给质量团队或者用户，以供评审。如果通过评审，代码就被发布。如果未通过评审，那么需要变更后再提交。

持续部署（Continuous Deployment）：代码通过评审并发布后，自动部署到生产环境，以交付最终用户使用。

DevOps是一组完整的实践，涵盖自动化软件开发和IT团队之间的流程，以便他们可以更快速、更可靠地构建、测试和发布软件。

企业实施DevOps的收益主要在于大幅提升软件的交付速度。这里，我们将使用洛克希德·马丁公司的案例进行分析。

洛克希德·马丁公司的F-22猛禽战斗机是世界一流的战斗机之一，这得益于其隐身性、速度、敏捷性和态势感知的独特结合。洛克希德·马丁公司与美国空军合作，开发敏捷的新方法，以更快速、更实惠的方式向F-22猛禽战斗机提供关键能力。F-22猛禽战斗机是世界上最先进的战斗机之一，要保持技术优势，就必须不断关注快速创新。

传统的瀑布式开发过程无法足够快地为战斗机提供关键能力。以前洛克希德·马丁公司花了五到七年的时间来确定需求并为现有架构（F-22最初于20世纪90年代初期建立）发布新功能。这一耗时的过程，再加上代码质量和集成问题，产生了繁重的返工和自定义工作，导致该模式不再符合洛克希德·马丁公司对软件主导的创新的期望。

对于洛克希德·马丁公司而言，保持F-22猛禽战斗机的领先地位不仅仅在于升级其硬件和部署现代软件平台。相反，他们还寻求建立植根于创新和协作的团队文化，将创新和敏捷的方法运用到应用程序开发中。

为此，洛克希德·马丁公司希望采用软件词典中常见的原则和框架，例如敏捷、最小可行产品（MVP）和DevSecOps（融入了安全的DevOps）。

通过红帽开放创新实验室在洛克希德·马丁公司为期八周的驻留，红帽公司协助洛克希德·马丁公司采用一种敏捷的方法论和DevSecOps实践替代了用于F-22猛禽战斗机升级的瀑布式开发过程，从而更快速响应美国空军的需求。

洛克希德·马丁公司和红帽共同创建了一个基于红帽OpenShift容器平台的开放架构，这使F-22团队能够加快应用程序的开发和交付。

洛克希德·马丁公司选择红帽开放创新实验室来带领他们完成敏捷转型过程，并帮助他们在F-22上实施开源架构，同时解开其嵌入式系统网络，从而创造出更敏捷、更适应美国空军需求的产品。红帽开放创新实验室通过指导方式帮助洛克希德·马丁公司的团队采用了敏捷开发方法和DevSecOps实践。

在一次探讨会议和架构审查之后，红帽为洛克希德·马丁公司建立了一个基于红帽OpenShift容器平台的环境，该平台是值得信赖的企业Kubernetes平台。OpenShift针对开发人员的创新模式进行了优化，同时帮助客户应对安全、运营管理以及应用程序和容器管理集成方面的IT挑战。

OpenShift由Red Hat Enterprise Linux的可信赖基础提供支持，Red Hat Enterprise Linux是业界最受认可的操作系统之一，也是第一个支持Linux容器技术并获得Common Criteria认证支持的操作系统，从而使该平台非常适合满足由洛克希德·马丁公司及其客户制定的高安全标准。

在红帽开放创新实验室与洛克希德·马丁公司合作期间，一个由五个开发人员、两个运维人员和一个产品负责人组成的跨职能团队共同合作，为OpenShift上的F-22开发新的应用程序，取得了良好的效果。随后，洛克希德·马丁公司用6个月时间，将OpenShift、敏捷方法和DevSecOps的成功经验扩展到了100人的F-22开发团队。

洛克希德·马丁公司的敏捷转型已获得回报。在最近的一次启动会议上，F-22猛禽战斗机Scrum团队将其对未来冲刺的预测能力提高了40%。项目启动仅一年之后，洛克希德·马丁公司就计划在飞机上提前三年交付新的通信功能。洛克希德·马丁公司正在继续将此方法扩展到整个F-22开发组织。

红帽开放创新实验室与洛克希德·马丁公司合作，不仅改变了其文化、流程和技术，而且还促使其重新考虑了团队的实际工作方式。洛克希德·马丁公司的F-22猛禽战斗机开发团队通过拆除壁垒创造了一个开放的工作环境，从而推动DevSecOps文化的进一步推广。

我们先通过一个简单的例子来了解什么是云原生DevOps，它和DevOps有什么不同。

上图是一个大排档，图中的大厨在非常努力的去切、炒、制作各种美食，并将它卖出去。

从原材料的采购到加工到销售到售后，都是一两个人完成。这是非常典型的DevOps场景，团队搞定端到端的所有的事情。

这种情况，当厨师水平比较高、销售能力比较强的时候，可以做到高效率、低浪费。但存在的问题是，想要规模化会很难。因为它的流程都是非标准的，需要厨师有很强的个人能力。

我们再看这张南京大排档的图，虽然名字里有大排档，但它显然不是我们上面说的大排档。我们随便走进任何一家南京大排档，都可以发现，南京大排档的厨师，可以专注在为客户提供更好的菜品上，研发试验新菜品，并通过小批量的用户来尝试和推广。无论是用户量增加或减少，都能很快的去适应。店铺扩张也可以很快。这种我们可以理解为云原生DevOps。

云原生DevOps是充分利用云原生基础设施，基于微服务/无服务架构体系和开源标准，语言和框架无关，具备持续交付和智能自运维能力，从而做到比传统DevOps更高的服务质量、更低的开发运维成本，让研发专注于业务的快速迭代。