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