企业在努力实现业务敏捷、推动朝着对工人的个性化支持以及集成业务流程的组合发展。应用集成项目必须权衡这些要素。要平衡好这些要素会涉及到三个功能领域的产品：前我们介绍了工作流产品， 组件目录管理，本文将继续介绍第三类产品即开发与运营集成。

部署和运营集成

虚拟化和云计算给企业应用集成增加了一个新的维度，因为它们替托管应用和组件引入了动态资源的概念。此外，开发高度组件化应用的趋势已经导致了部署应用的任务的复杂化和容易出错。集成显然需要找组件以便连接之，所以组件托管点的弹性分配会对集成产生重大影响。自动化部署和重新部署降低了风险，这是其重要的原因。

对部署于操作集成产品的任何讨论都得从两款统治性的工具开始，一个是Chef另一个是Puppet。应用供应商、硬件供应商以及操作系统供应商一般会提供其中1个或全部给自己的用户，理解它们的主要区别很重要，这不仅是为了在两者都有的情况下支持做出选择，也要理解部署和运营的趋势。

Chef是基于脚本的，这意味着你是通过编写特殊部署指令来使用Chef。对于习惯用部署脚本来加载应用的公司来说，用Chef来过渡通常比较简单。Puppet是用所谓的模型驱动法来部署运营。它是对想要的结果进行建模的描述性语言，也是将该模型转换为步骤来实现目标的处理器。

像Chef这样基于脚本或“过程性”方案比较受主流用户喜欢，因为它们是从目前的做法自然演进而来的，不过基于模型或“描述性”运营工具似乎是业界趋势。这是因为基于模型的方案可以更容易地在云环境应用，其部署条件要取决于你往云里面放什么东西。然而，你可能得小心审查Puppet工具以确保自己喜欢供应商支持的框架。Chef和Puppet都是相关应用的独立套件组成部分，总体的混搭效果可能会令人眼花缭乱或吓人。

概括DevOps工具领域永远都是有风险的。一般来说，Chef更加灵活但也更难学习。对于简单的部署和运营任务来说，Puppet可能是更好的选择。

在云端同时用Chef和Puppet是可能的，但云部署和运营有自己的一套工具。如果你的应用可以明确区分为云托管的部分和数据中心托管部分，云那部分最好还是用基于云的工具来部署和运营。Amazon的OpsWorks是用得最广泛的云部署和运营工具。它基于Chef，这意味着它更容易与Chef集成来管理同时涉及到公有云和数据中心的部署。

如果你希望要更加以云为中心的东西，有一个目前正在崭露头角的规范可以考虑，它是结构化信息标准促进组织（OASIS）的TOSCA（云应用拓扑与编排规范）。TOSCA是对于云和数据中心部署和运营有着很大潜在用途的脚本和模型的组合，但还很新。IBM的Cloud Orchestrator是领先的TOSCA产品。如果你是IBM客户，Cloud Orchestrator是非常强大的解决方案，但对于非IBM公司来说采用会比较难。

至少有一个供应商相信，未来是广泛动态总体自动化工具包的天下。自动化提供了全美的业务集成和自动化产品。他们为各种平台（包括公司有可能正在使用或考虑使用的数据中心和云资源）提供了工作负荷、服务和发布自动化。作为企业应用集成的全方位解决方案，它们可能是无与伦比的，但也可能是最难与当前应用、工具和实践集成的一个。

确保未来和当前需求得到满足

在“应用开发”的前沿，应用是通过自动化部署工具随地创建并通过敏捷工作流控制来使用的。静态应用的传统观念已经过时，所以你需要开发什么应用，要怎么把它们链接到业务流程里面都有一套工具来管。在数据中心或者云的部署又是另一套工具。不过现在已经有了更为面向业务、可适应米姐组件和敏捷资源的集成愿景的早期迹象。

这就是你的企业应用集成必须针对的未来，从长远来看对你来说是有价值的。IT正在以前所未有的速度变化着，因此，确保你的未来需求跟当前需求一样得到考虑，确保你的供应商的未来方向跟当前产品一样受到仔细评估至关重要。无论你的业务需求要求什么，最好的选择都是让你可以共处最久的那个。