集成是几乎所有的现代应用开发计划的必需元素。多年以来，SOA以及前端Web开发的经验已经就集成教育了策划者和架构师。早期的虚拟化经验更多的扩展了这一点，但是云打破了很多现代集成实践，因此策划者和架构师需要通过询问为何云是不同的来开始其云集成项目。随后，他们需要在心里评估云集成计划。对于大多数而言，关键的一点在于如何在云部署环境中调节应用集成工具。

在早期的应用中，开发者要么编写整体的应用，要么在一个通用的装载映像中紧密耦合独立的组件。大量的应用仍旧以这种方式编写，但是SOA和敏捷开发已经开始鼓励架构师构建独立的功能组件，可以利用这些组件来组件应用。随着业务应用同业务流程以及其它流程越来越多地集成，他们需要更为松散的耦合组件，简单地消除单一的巨大装载映像。

基于目录的集成组件已经成为一种规则。通过基于目录的集成，一个组件注册库本身在某个地方，而且通过这个注册可以分配并且发送工作。目录可以相当简单，比如DNS，或者是一个基于功能浏览的注册库，理论上SOA UDDI就是。不过在所有情况下，这个目录都被期望在首次使用时创建一个加载组件或者触发器组件加载的链接。

云计算从两方面对这些造成了挑战。首先云假定了一种高水平的动态资源分配。组件可以放到云中的任何地方，而且如何接触到这个组件的问题边界很少，同时过去你可以假设所有的一切都至少在一个固定的数据中心中存放。第二，云的原则目标之一就是通过组件实例的可扩展管理灵活性和性能。这也意味着，很多组件必须实时共享工作或者故障恢复。通常创建集成到组件的链接的过程并不是瞬时的，而且在延迟阶段，事务处理可能受到牵连。

满足这些挑战的关键是评估云计算，识别集成痛点所在。首先，要关注任何地方的组件可以在加载或者故障恢复情况下云资源化。此外，要关注云组件被云提供商重新分配以响应问题的情况。任何这样的场景都需要一些同其他组件和工作流的特殊集成处理。

云用户表示更加偏爱基于DNS的负载均衡，将其作为工作到云的组件的一种方式，可以实现故障恢复或者水平扩展。在可扩咱的情况下，基于DNS的负载均衡允许同当下的组件连接工作，同时增加一个新的，因此QoE伴随的唯一风险就是组件失败，这也是大部分公司要接受的。如果任何的宕机时间都无法忍受，那么至少通过任何点的两个可用组件副本和通过DNS集成来解决。

基于DNS的负载均衡的问题在于并不支持组件浏览（没有WSDL）而且可能导致工作流到组件的状态问题。如果出于这两个原因没有可能使用基于DNS的负载均衡，下一个最佳的战略就是依赖于UDDI和WSDL或者BPEL来在组件之间进行选择。如果管理组件链接的应用控制流程无法为云端转移组件负责，就会出现潜在的问题。如果转一个组件改变了地址，组件就会处于未链接状态。亚马逊的解决方案是弹性IP地址，让静态URL引用动态组件。这种地址转换的方法也可以用在私有云中。

亚马逊弹性IP地址模型展示了云集成的一个基本事实。有两种形式的“组件移动性”：一是必须识别出独立的组件作为分立的元素可以链接到工作流中，另一个是识别出通过云流程创建的继承组件副本，而非通过应用流程储藏间。如果你接受URL是逻辑组件移动和物理组件位置之间的边界的原则的话，用标准化集成工具（包括DevOps或者CAMP）调节这种组合更容易。

集成工具应该用于将组件带到一起，因为工作流必须直接同其单独接触。这个工具的目标就是直接同URL工作，并期望这个URL随后可以通过独立的后端集成流程匹配资源。

以地址组件改变时通过资源管理器调用工具为条件，在一个集成工具中通过URL管理地址表达是可行的。关键问题在于不是管理这种改变，而是管理处理中的事物改变产生的影响。允许任何静态的流来改变基础中流是非常危险的。会导致所谓的“结束时期”。因此在改变URL的目标地址之前，这对于静态工作流来报告处理中的事物的失败可能是最佳的方式。

安全和法规遵从是任何集成列表上最后的元素。工作流可能呈现为相对有状态的、末端安全和法规遵从问题，但是就算组件链接可以导致问题，应用安全审计可能会发现。组件弹性带来了多种机遇，引出了非真正的组件版本。最终，云端需要更多的集成工作来确保工作流通过弹性资源使用来维持，你需要更多的内容来检查你的组件正常处理，保证你将唯一合适且真实的元素带入到你的工作流中。