定义 DevOps 2.0：统一工具 + 环境整合？

UnitedStack 的运维工程师 Jim Jiang（ @蒋闻天）同学在自己 11 月底的一篇博客文章《 DevOps 2.0 》中提出了自己对 DevOps 理念及相关工具演变的一个解读。他在从宏观角度分析了 Foreman、Puppet、Juju、Razor、Crowbar、Chef 和 TripleO 整个体系的关系和异同之后提出了一个观点：

我将 TripleO 之前的 DevOps 称为 DevOps 的 1.0 时代，而 TripleO 之后的 DevOps 称为 DevOps 2.0 新时代。2.0 时代的一个显著特点是任何 DevOps 行为都有 API，通过在外部编写程序我们可以主导 DevOps 的整个过程。

在 Jim Jiang 同学看来，DevOps 世界的本质其实是五大块：Provison，Software Install，Configuration，State Management，以及 Orchestration。

五大块的定义分别是：

1. 自动把系统和软件安装好，不管是物理机还是虚拟机。（Provison）
2. 对机器上安装的程序进行配置并且进行统一管理和收敛。（Configration）
3. 掌控集群的状态，不管是资源状态还是安装状态，只要是状态我们都需要知道。（State）
4. 在集群上方便的安装软件 （Software）
5. 编写一个剧本将资源的调度和软件的配置协调起来。（Orchestration）

Jim Jiang 同学对现有的各个运维自动化工具列了一个表格：

上图中除了最底层以外的其他工具都无法覆盖所有的五大块，因此 Jim 同学说：

传统的 DevOps 不是缺胳膊就是少腿，整合起来很尴尬。

最重要的是，在传统的 DevOps 工具下，

整个架构被一刀切为了两部分，管理物理设备的部分和管理虚拟化两个部分。

… …这个方案看起来很不错，但是要运行起来关键是要一个粘合程序，能协调全部的工作，否则离不开人工干预。

……粘合程序为了迎合其他组件而做出一些不得已的妥协，和臭名昭著的中间件是一个道理，会变得越来越臃肿，越来越和初衷不同，等到实在忍受不了这种事情了以后必然要重构。

那么 Jim Jiang 同学提倡的 TripleO 又是怎么一回事呢？这在他的另一篇文章《 TripleO, Openstack Deploy On Baremetal Openstack 》进行了更加详细的描述：

TripleO 的目标是简化 OpenStack 部署，它开发了一个自运维的 OpenStack 基础设施，它由裸机安装部分 (nova baremetal or ironic)、软件安装部分 (diskimage-builder)、Orchestration 工具（Heat）、镜像内 DevOps 工具 (Puppet Or Chef) 组成。

TripleO 这个名称的来源是“OpenStack deployed on and with OpenStack”这个词组，意思是“用 OpenStack 部署，部署在 OpenStack 之上的 OpenStack”。

这样做的好处是什么呢？Jim Jiang 同学总结了两点：

1. 只用一个工具就能把一个集群管理起来，不用依赖于一大堆第三方工具的堆砌
2. 用 Ironic 组件屏蔽了物理层的实现，抽象出相同的接口给 Nova 调用，对上层透明

Jim Jiang 不是第一位提及 DevOps 2.0 概念的同学。在 2012 年 6 月，GigaOM 上发布了一篇名为《 Star Trek’s Dr. McCoy and DevOps 2.0 》的文章，最早提出了 DevOps 2.0 的概念。该文作者 Dave Roberts 是 ServiceMesh 公司的 CMO、战略 SVP 和布道师。

Dave 在文章中对 DevOps 提出了如下定义：

DevOps 有点像是《星际旅行》里面的那个传送装置。DevOps 的目标是创建一系列流程 + 工具的组合，这套组合可以将一个现代企业应用在它的开发环境中解耦，再在宇宙另一端的生产环境上重现。传送后的应用必须能够保持正常运行的状态——有求必应。

Dave 描述的“传统 DevOps”跟“现代 DevOps”最大的区别在于，传统 DevOps 对底层物理设备的管理无能为力，而 DevOps 2.0 则可以将防火墙、负载均衡一并纳入。这点和 Jim Jiang 同学的观点一致。

纳入物理设备也可以用另一种方式理解，那就是“带着环境一起走”：

环境本身也成为了软件设计中的一部分，并跟随应用逻辑一起，从生命周期的一个阶段转入下一个阶段。

无独有偶，在今年 QCon 上海《来自一线的敏捷实战》专题上，爱立信软件开发高级专家蔡煜（ @larrycaiyu ）分享了一个建设建立了 ETA (Environment Tools Automation）团队的经验。蔡煜认为从团队的角度来看，一个团队如果光做工具，或者光做版本控制，光做持续集成，光做自动化这些，那么是很容易被孤立的，发展的空间很小，也没有成就感。而 ETA 这三部分工作如果有机会合在一块，事情的发展就会顺利的多。虽然跟 DevOps 这个话题没有直接的关系，但表明在其他领域也有人关注环境与软件整合的问题。

你对于 DevOps 2.0 的概念怎么看？或者换句话说，你对于物理环境和虚拟环境统一管理、环境本身与软件设计的整合这样一个方向有什么看法？欢迎交流！