集成是幾乎所有的現代應用開發計劃的必需元素。多年以來，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的目標地址之前，這對于靜態工作流來報告處理中的事物的失敗可能是最佳的方式。

安全和法規遵從是任何集成列表上最后的元素。工作流可能呈現為相對有狀態的、末端安全和法規遵從問題，但是就算組件鏈接可以導致問題，應用安全審計可能會發現。組件彈性帶來了多種機遇，引出了非真正的組件版本。最終，云端需要更多的集成工作來確保工作流通過彈性資源使用來維持，你需要更多的內容來檢查你的組件正常處理，保證你將唯一合適且真實的元素帶入到你的工作流中。