似乎大家开始越来越倾向于把DevOps拿来跟“orchestration”联系在一起。Tom Nolle解释了它们之间的共同点和区别。

云、软件的组件化以及对持续交付的需求，这几个因素加在一起对应用产生了深远变革。没有比在部署和运营生命周期领域变化更重大的环节，一度被称为“DevOps”的这个领域似乎正在演变为所谓的“orchestration”。

为了确保开发和运营能够持续同步演进，开发者需要理解这些趋势。这要求开发者理解DevOps与orchestration的差异，对自己的开发和运营策略进行重新思考，并且对重要的新兴趋势保持警觉。

orchestration究竟是什么意思

应用从开发到部署的演进总是多种实践的联姻。牵涉到应用的一共有4组不同的工具集。版本控制和开发管理加上开发过程一起再将其连接回企业架构模型。DevOps巩固然后把开发过程连接到部署和应用生命周期管理。

“orchestration”这个词迷惑了许多开发者和架构师，因为他们并不清楚发生了哪些改变。orchestration描述了一个范围很广的应用软件自动化的过程，有可能会涉及到应用开发和运营的四个实践领域。它很大程度上改变了已经自动化的工具，尤其是DevOps，改变之大以至于orchestration有时候纯粹被视为DevOps的演进。它还增加了一个覆盖开发部署剩余范围大部分的自动化维度。

orchestration的共同驱动力是更加敏捷性和个性化应用的需求。这一点在基于移动的前端过程、移动后端及服务以及基于微服务的应用中已经体现出来。这些趋势跟虚拟资源和云计算集合创造出两个维度的变量。这就是为什么需要在加快过程和减少错误中利用自动化的原因。

新的开发和部署结构

最好把现代开发和部署形象地描述为二层架构。顶层是同意开发过程软件开发的敏捷或持续交付层，现在这一层已经嵌入到应用生命周期管理中。底层是DevOps的现代化形式，旨在为高度组件化（如果你愿意的话也可以称为“微服务化”）应用以及虚拟化资源服务。

要想让这一新结构发挥作用，最关键的一点是在整个应用生命周期ALM工具跟DevOps工具是完成集成在一起的。这类集成一直都会有好处。但如果通过软件自动化进行持续交付和创新是目标所在。在现代应用模型中，持续交付的努力以及敏捷开发必须直接在服务本身以及部署和维系它们的DevOps框内进行。这就是orchestration要明确的东西。

过程变得像服务

持续交付和DevOps必须集成的概念对很多人来说似乎并未深入人心。毕竟，DevOps总是意味着要定义开发和运营的关系。问题在于在云和敏捷开发的世界里，DevOps过程几乎必须当作服务或组件来考虑。这类关系在IBM、微软以及Oracle等集成软件供应商以及Red Hat等开源形式的工具包中已经有所体现。

有了持续开发和DevOps集成，DevOps模式或者每一ALM阶段相关的菜谱必须遵循ALM流程进行设计。然后再用DevOps语言编写出来。当应用、组件或服务进行开发变更时，不仅要对变更进行应用功能测试、安全测试以及合规性测试，而且还要测试变更对ALM与DevOps间集成的影响。

持续交付要求的开发、ALM以及DevOps之间的紧密耦合已经改变了DevOps。两个最受欢迎的工具，命令式的Chef以及陈述式的Puppet均已演进为支持资源的模块化声明。这反过来又支持了组件和服务部署的虚拟化以及模块化定义，从而有利于重用和模块化部署。第二代额DevOps工具，比如Ansible或者SaltStack从一开始就支持这些能力。

集成方面的考虑

连接DevOps、持续开发与ALM相关的API问题或者集成并不是一个很大的挑战，但是这些问题一定不能忽视。

“模块化”这个词很有魔力。DevOps模型或者脚本永远都应该基于组件级或者服务级元素来构建应用。ALM无论哪个阶段需要混合模型，这些模型都应该以简单的方式与产品部署模型连接起来。

事件控制

另一个关键的考虑是生命周期管理的事件控制。没有事件控制，资源过程就不能将条件传送给生命周期管理和部署过程，从而无法进行自动化处理。

DevOps工具中的事件处理至关重要，如果orchestration中被用到的话。一般而言，支持新兴“基础设施即代码”模型（Chef和Puppet均支持）的DevOps工具都会处理事件，但你也可以看看其他一些工具有没有事件处理自动化的能力。

放眼未来

orchestration就是自动化一切与持续交付、敏捷开发相关的东西，这个概念可能最终会把当前的所有工具都归并到一个持续生命周期流程里面。实际上，似乎这是可真正确保未来软件开发实践能跟上业务节奏的唯一结果。

提供所有合适工具的供应商也会拥有最好的机会，即便你目前依赖的是其他工具。最起码，它们会有助于构建一个关于orchestration的未来。