云编制和集成服务可确保IT生命力

对云计算感兴趣的企业可能已经意识到，很多厂商现在提供集成和编制服务，并将其作为他们云计算服务中的一部分。对于很多人来说，这一转变看上去似乎只是创意营销，因为目前的用户会发现在云计算和传统IT之间的编制和集成基本上是没有什么差别的。随着云计算的不断发展(但是这一趋势将会改变)，云计算规划者必须解决由特定云计算的应用程序所带来的影响。

对于企业来说，云计算还处于一个过渡状态中。早期的云计算应用主要集中于服务器整合和开发/测试。那么，这一阶段的云计算还是一个近乎静态的工具，它与企业IT投资组合剩余部分的集成是微不足道的。而如今，企业正在寻找完全没有在他们传统数据中心系统运行过的云计算应用程序——这类应用程序是专为云计算的动态特性而设计的。把这些应用程序与用户、与其他的应用程序以及甚至与这些应用程序相连就显然是一个新的问题了，这个问题推动开发运营和部署更多地关注与编制、集成以及管理相关的问题。一个云计算规划者需要做出的最关键决定就是跨越“基本”开发运营和先进编制与集成的边界。

跨越云计算编制、集成

编制是指应用程序组件的部署和连接。集成是指在组件之间满足接口以支持工作流的过程。很显然，这些功能是相连的。当应用程序部署在静态资源上时，一组通常被称为开发运营的工具可提供这两种功能。增加云计算意味着必须满足改变资源分配或者必须打破应用程序工作流。

应用程序通过网络实现的API来实现功能，而API可为应用程序内(水平)流量和用户(垂直)流量提供工作流的途径。当部署一个应用程序组件时，它会被分配一个地址，这个地址必须用于链接其接口和其他组件与用户的接口。编制可创建地址，可互联所部署的组建，但是仍然需要集成来让用户访问新的应用程序，并可让新的应用程序与其他已部署的组件建立链接。

编制和集成在复杂性方面将会有所不同，这主要取决于在部署过程中涉及有多/少的变量或创建了多少个变量。云计算将总是增加动态性和可变性，所以任何云计算项目都应当包括对两种工具的具体检查以及编制与集成的措施以便于在较长期范围内实现稳定的和可支持的运行。

当研究云计算项目的集成和编制选项时，考虑如何应对动态性问题(尤其是云计算应用爆发和故障转移)和应用程序的功能综合将是非常重要的。

为复杂的动态云计算映射应用程序工作流

在云计算编制和集成中审查特殊处理应用程序的一般规则就是映射应用程序的工作流。这一做法有助于确定信息流出应用程序组件集合外的频繁程度以及应用程序内部工作流的复杂程度。当与云计算托管组件共同使用时，高度互联的工作流会迅速超过部署和集成的传统做法。

基于云计算的开源开发运营工具(例如HEAT、Puppet、Chef和Juju)可以适应服务器/虚拟机资源的动态分配和部署云计算应用程序。如果你设置工具返回它们所使用资源的地址，那么这些地址就可用于集成组件和编制可连结性。然而，随着组件数量和应用程序动态性的增加，跟踪组件地址和映射工作流连结性的复杂性也会爆炸性地增加。IBM、微软、Oracle、思科、BMC以及其他的厂商可提供商业编制工具并将其作为他们云计算产品组合的一部分，从而简化这一复杂的过程。随着云计算应用程序从静态转变为动态，这些工具可以提供一个更好的方法来进行编制和集成，因为它们可以处理大量互相连接的组件。

为云计算爆发、故障转移实施专门的编制

如果云计算应用程序会遇到大量的云计算应用爆发或故障转移，那么可能还需要专门地编制/集成这些云计算应用程序。在这两种情况下，组件工作流的编制将动态地变化以响应负载变化或故障事件。这一动态性意味着组件之间和与用户的互连性可能也必须做出相应的改变。与传统的编制和集成不同，这些改变必须让用户很少或没有感受到中断事件，而且它们应当可以自动由系统通知或识别的多余工作负载所驱动。

实际上，云计算爆发和故障转移都会让编制和集成进入管理流程，而商业工具往往可以更好地与应用程序管理进行集成。

大多数的编制/集成问题都归结为在目录中报告所部署组件的位置，以便于用户或其他组件能够找到它们。RESTful应用程序通常会使用DNS;SOA应用程序可能会使用UDDI;而这两种应用程序可以使用诸如LDAP的目录协议以便于维护应用程序组件之间的链接。寻找可自动升级这些目录链接的编制/集成工具。

但是，几乎所有的云计算爆发和故障转移应用程序也将需要某些负载平衡的形式以便于把工作负载分配给更多的(或可替代的)组件。负载平衡器将典型地必须被配置为定位每个它所控制的组件的位置。请确保你的编制/集成工具可允许这一点。

为综合准备云计算应用程序

很少有用户正在考虑把所有的一切都迁入云计算，所以适应保留在本地服务器或者甚至桌面系统上的应用程序功能是非常重要的。你将需要把动态云计算组件与静态的、数据中心托管的应用程序相链接。

当云计算用于备份或补充传统IT应用程序时，就会出现最复杂的编制/集成需求，原因有两个：因为这会创建一个动态托管和静态配置的混合体，也因为传统应用程序是通过单独的应用程序生命周期管理(ALM)流程来管理。此外，对于复杂需求考虑使用商业工具是有帮助的，你可以从摸索已在使用的ALM包的编制/集成功能开始。