编者按：从早期软件工程的独立性，到1990年代对软件工程的重视，到今天已经完全演变成一条产业链。这就是我们现在所说的DevOps。本文从DevOps的起源与发展、DevOps的演进及其关键使能技术、如何选择适合自己的DevOps系统三个方面详细阐述了系统的演进过程。作者的微博是：@fit2cloud，如果有对DevOps感兴趣的朋友可以和我一起讨论。一、DevOps的起源和发展在过去的几十年里，为了按时交付软件产品和服务，人们越来越认识到传统的开发和运维分离的做法已经不适合现代的产品和服务开发。需要。因此，将开发和运维作为一个整体的DevOps工程思想逐渐流行起来，逐渐产生了对DevOps系统的需求。希望有一个平台或工具来支撑开发运维的交付以及后续的环境。管理工作，即需要一系列的持续集成、持续交付、自动化部署、自动化测试监控、自动化伸缩、自动化恢复系统，以提高开发、测试和运行过程中的部署效率，简化管理开发、测试和维护流程，并降低交付成本。风险，降低沟通成本和运营成本。广义上讲，无论是云管理平台工具（如RightScale），还是各种PaaS平台（CloudFoundry、Heroku等），或者自动化部署工具，如Chef、Puppet、Ansible等，本质上都是属于DevOps系统，都是为了解决开发过程中交付环节的问题和交付后的运营管理问题，即在开发和测试过程中，帮助开发和测试人员搭建和管理环境，让他们可以在更改后部署更改以进行测试；在运维和支持过程中，帮助运维支持人员对系统进行升级，扩容和重建恢复系统，并能持续掌握升级后系统整体和各个栈的状态，从各个层面对系统进行监控，扩容还原系统，还原系统。近年来，随着云计算和容器技术的进步，以及产品业务对IT能力的需求，DevOps体系发展越来越快，其作用和概念也越来越清晰和独立。回顾其发展路径和过渡过程，我们认为基本可以分为三代：基于物理机或独立虚拟机的部署时代、基于IaaS可编程资源的部署时代、基于容器的部署时代.随着这三代的提升，DevOps体系的整体能力越来越强。我们先来看看每一代DevOps系统的特点和能力，然后进一步对DevOps系统进行分类，以帮助我们选择合适的DevOps系统。2.DevOps的演进及其关键使能技术1.基于物理机/独立虚拟机的部署时代这是第一代DevOps系统，其特点是静态配置+手动协调+仅部分应用自动部署.在构建整个应用系统的过程中，首先需要在DevOps系统之外创建应用运行所需的资源环境（如主机、网络、存储等）。DevOps系统对这部分没有控制权，只负责资源环境搭建完成后的自动化。部署一个应用，资源环境的搭建和后续的应用部署过程是分开的，需要人手动协调和控制，即资源环境搭建完成后，时间由人控制，配置由人手动完成资源环境准备好后修改（如各种主机IP地址、登录密码Key信息），然后手动运行自动化脚本工具，如Shell、Python、Ruby脚本，安装、部署、升级应用，添加或添加后减少节点，也需要手动运行自动化脚本配置系统无法实现包括资源环境创建或节点变更到应用部署全过程的一键式部署，即集群感知+自动协同控制+动态配置+全流程堆栈自动化。目前可以说大部分DevOps系统还停留在这个阶段。由于DevOps系统还没有实现基于集群感知的资源环境创建自动化和协调自动化，现阶段DevOps系统的能力会造成如下影响和后果：创建系统资源环境效率低，耗时长，并且有风险，尤其是在创建具有复杂结构的复杂系统组件时；创建系统资源环境的过程需要专门的网络工程师和系统工程师，无法实现开发、测试、运维人员的自助服务。系统越复杂，沟通成本越大，开发和维护过程的管理也越复杂；整个系统的创建需要网络工程师、系统工程师、开发人员的参与和配合。系统组件越多，结构越复杂，通信成本就越大。运维流程管理也比较复杂，费时费力，协调麻烦，风险高，容易出错；当系统资源环境发生变化时，如增加或减少主机，由人手动协调和控制，部署和升级所需的IP是手动静态配置的。、登录密码或Key等信息，导致变更过程风险高、效率低，尤其是在系统庞大复杂的情况下；交付过程风险高，开发测试产品环境不统一，经常出现一个环境运行正常，另一个环境不正常的现象这里需要提到的是，虽然很多组织已经在使用IaaS（比如阿里巴巴云）创建虚拟机来构建应用系统所需的资源环境，他们还没有实现集群感知，整个系统环境创建的自动化还卡在了里面。半自动化阶段（比如启动一组包年包月虚拟机后，手动配置部署脚本需要的IP地址、登录密码、登录密钥等信息，然后手动运行自动化脚本部署），所以这种方式还是属于第一代DevOps体系。同时，这也是国内大部分组织DevOps的现状，在自动化和效率上还有巨大的提升空间。2、基于IaaS的部署时代这是第二代DevOps体系，特点是集群感知+自动协同控制+动态配置+全栈自动化。借助云计算IaaS资源的可编程性，这一代DevOps系统实现了集群感知、自动协同控制、动态配置、全栈自动化，即实现应用组件的一键式创建和安装。环境创建到部署和安装。部署，在创建后阶段，可以实现集群感知（Cluster-Aware），即根据环境的变化自动部署和配置系统。例如，当某网站业务量增长需要扩容时，人为增加web计算节点时，可以在新增加的web虚拟机启动后，自动安装web组件，将各个web服务可以在负载均衡服务中注册和配置虚拟机。收缩时，它会自动删除。这个过程不需要人为协调和控制。DevOps系统可以根据集群的变化自动配置集群。目前这个级别的DevOps系统还是比较少的。因为现阶段DevOps系统的自动化管理涵盖了环境创建和变更、应用组件部署自动化，以及环境创建、集群感知、应用组件部署自动化、各个流程的协调和控制，与第一代相比，DevOps系统这一阶段将为开发运维工作带来以下巨大提升：开发、测试和运维人员可以自行创建环境和部署系统。系统越复杂，沟通成本就越低。运维流程管理复杂性风险越低，例如只能由具有专业知识的工程师来完成。如果需要的时候工程师不在，会很麻烦；创建环境和部署高效、自动化、快速、时间少、风险低；当系统资源环境发生变化时，如伸缩，增加或减少主机后，可以实现集群感知，动态配置集群，提高变更过程的效率，降低风险，尤其是在系统组件庞大复杂的情况下；需要快速搭建环境，满足各种测试、演示、在线扩展。需要能够按需创建、启动、关闭开发和测试环境，节约成本，提高开发、测试和交付的效率。3、基于容器的部署时代这是第三代DevOps系统，其特点是在第二代的基础上，增加了应用跨云移植。（基于容器技术）。借助云计算IaaS资源的可编程特性和Linux容器技术，不仅实现了集群感知、自动协调、动态配置和全栈自动化，还实现了应用的跨云迁移和弹性伸缩，消除了针对开发、测试、生产环境的不一致性，避免应用锁定在某个IaaS上，将所有基础服务IaaS和物理机变成一个公共资源池，提高资源利用率，大大提高IT开发、建设和手术。它带来了更多更大的想象空间，这也是为什么Docker和Kubernetes现在非常流行的原因。例如：如果我们要将一组服务从AWS迁移到Azure，那么我们就得从头开始创建一组虚拟机镜像和虚拟机，配置和安装系统或应用的组件，如果系统复杂庞大，这个过程还是需要花费大量的时间和人力，并且依赖于一些具备这方面知识的工程师，但是在容器技术和相关容器工具的支持下，这个过程会变成一个非常快速和简单的过程，成为自动化的在Azure等目标云上启动所需的标准虚拟机，然后下载容器镜像、配置启动容器、配置相关DNS等，真正实现便捷的跨云迁移和弹性动态伸缩服务。再举个例子，目前谷歌开源的容器管理系统Kubernetes可以说得到了业界的广泛认可和支持。当我们准备好应用系统的Docker镜像后，只要在各种IaaS上有支持Docker的环境，比如Kubernetes集群，那么我们就可以在不同的IaaS上快速方便地迁移应用系统或扩容。下图是基于FIT2CLOUD的跨云部署管理方案。我们希望未来用户可以使用FIT2CLOUD在多个不同的IaaS上创建Kubernetes集群，通过Kubernetes管理和部署应用系统。之后我们会有新的文章分享FIT2CLOUD如何创建和维护Kunerbetes集群。上面我们介绍了不同时代的DevOps系统的特点和能力，那么我们是不是应该选择能力最强的第三代DevOps系统呢？？答案是不。每个DevOps系统都不是灵丹妙药。我们需要根据要管理的系统的需要，选择合适的DevOps系统或工具。在下一节中，我们将回答这个问题。3、如何选择适合自己的DevOps系统？目前，DevOps系统可以说是五花八门，功能差异很大，应用场景也不同。那么我们应该如何选择合适的DevOps系统呢？在这里，我们提出了一种基于目标系统分类的选择方法。我们根据要管理的目标应用程序或系统类型进行分类。对于目标系统，我们可以先把它分为三类，即IaaS服务系统、PaaS服务系统、应用系统，而应用系统又可以分为简单的Web应用系统、复杂的分布式系统，那么有了这样的分类，就可以了我们选择DevOps系统和工具相对简单明了。1、IaaS服务体系由于IaaS系统本身的创建是基于物理机的，适用于此类系统的DevOps系统或工具有Shell、Chef、Puppet，以及IaaS服务商自身开发的自动化运维.管理系统只能使用第一代基于物理机的DevOps系统。2、PaaS服务体系如果PaaS不部署在IaaS上，本质上就不是PaaS，因为它不具备弹性和自动伸缩性。真正的PaaS系统部署在IaaS上，为开发、测试、运维人员提供服务。那么适用的DevOps工具可以是RightScale、Scalr、Cloudformation、Opsworks和FIT2CLOUD，它们是基于IaaS可编程资源的第二代DevOps。系统，当然你也可以选择第三代基于容器的DevOps系统，但是第三代系统还在开发中，没有第二代那么成熟。3.简单的Web应用系统对于一个简单的Web应用系统，突出的特点是应用结构简单，比如只包括一个Web组件和数据库、缓存，或者一些常用的中间件服务等，而不包括一个分布式Component很多，那么对于这类系统，可以选择容器类的传统PaaS，即CloudFoundry、Heroku、OpenShift等。4.复杂的分布式应用系统对于复杂的分布式应用系统，容器类PaaS不能用来管理它们。它们只能通过定制的DevOps工具或系统进行管理，或者使用RightScale、Scalr、Cloudformation、Opsworks和FIT2CLOUD等云管理工具中的一种或几种组合，即基于IaaS可编程资源的第二代DevOps系统，也可选择第三代基于容器的DevOps系统。因为这样的工具为用户提供了对IaaS主机更大的控制权，并且在每个部署过程中提供了回调接口，实现了集群感知和每个部署过程的自动协同控制，即全栈自动化。本文来自：http://blog.fit2cloud.com/2014/12/14/devops-system-evolution.html
