?　　從時代的發展步伐來看，混合云集成將成為一種規則，因為混合云將成為主導模式。然而，在混合云環境中，很難確保所有應用程序都能很好地組合在一起。行業專家將幫助人們思考這一過程。

　　越來越明顯的是，很多采用云計算的企業采用的是混合云。如果應用程序將在公共云和數據中心之間移動，除了公共云之外，了解如何管理日趨復雜的應用程序集成任務至關重要。

　　首先要了解混合云應用程序集成的復雜性，重點關注每個變革的驅動因素如何影響整合以及工具的一致性與特定的集成問題。

　　如今幾乎所有的應用程序都是由不同的組件構建的，在不同的系統中加載和運行。大多數程序也必須與其他應用程序交換數據。這種應用程序意味著企業IT真的是一個工作流網絡，而這個愿景是二十年前推動面向服務架構（SOA）的動力。 SOA并不簡單，然而，在虛擬主機和應用程序動態擴展的世界中，它的設計問題似乎很簡單。

　　應用程序集成是連接組件和應用程序之間工作流程的過程。如今有這樣的機制來為傳統的數據中心托管，所以組織在混合云中必須關注的是這些機制是如何適應的。

　　大多數公司不希望完全修改應用程序集成策略;對其生產率、應用程序生命周期管理以及安全性和遵從性的影響將是顯著的。把重點放在適應的概念上，然后從需要適應的東西開始編目。

　　混合云采用對應用程序工作流有四個不同的影響：

　　（1）某些應用程序/組件托管在數據中心之外的場所，并受到不同的安全性，合規性和網絡連接控制和功能的限制。

　　（2）在某些情況下，云應用程序可以使用數據中心中不存在的云托管服務，而不是通過相同的方式實現，甚至在云提供商中也是如此。這些差異影響工作流集成和組件移動性。

　　（3）應用程序/組件可以動態移動，這意味著工作流必須遵循它們，并且可以在不同的連接/安全區域之間移動。

　　（4）云計算推出了動態擴展容量以匹配工作負載的概念，這在非云部署中很少提供。

　　成功的混合云應用程序集成最好是適應這些影響因素，首先是設計混合云環境，然后再適應/采用工具來解決每一個問題。雖然組織所采取的步驟可能針對上述列表中的特定驅動程序，但它們必須采取這樣的措施，以盡量減少敏捷混合云環境帶來的系統風險。

　　成功的混合云應用程序集成的第一步是在所有托管平臺/提供商之間創建統一的應用程序部署和連接模型。這意味著將“托管”定義為可以映射到任何云端或數據中心資源的抽象。

　　混合云集成中最大的錯誤是過度專業化。組織應該在整個混合云中建立一個通用的網絡連接模型，然后定義一個標準化的托管模型來部署應用程序/組件。

　　連接模型問題只能通過創建可以承載所有應用程序和組件的虛擬專用網來解決。越來越多的企業正在采用軟件定義或虛擬網絡作為其連接核心，如果采用適當的軟件定義網絡或軟件定義的廣域網模型，則無論是在云端還是數據中心，都可以連接所有內容。沒有替代開放的統一連接，所以這是正確的關鍵，企業認識到，基本的云網絡工具（例如，OpenStack的Neutron）最好用于補充企業虛擬網絡，而不是創建它。

　　一旦擁有合適的連接模型，標準化部署環境便于使用單個工具包來集成工作流。DevOps和基礎設施代碼（IAC）工具都支持標準的部署過程，并且它的支持隨著時間的推移而改善。

　　采取這一步驟將從根本上減少與混合云集成相關的任何特殊問題，甚至在某些情況下可以消除它們。然而，并不是所有的用戶都熟悉IAC的工具和功能，這些都是很重要的托管規范。

　　最后，查看DevOps解決方案的事件處理屬性。其強大功能將有助于管理操作生命周期。

　　第二步是根據安全性、遵從性和執行需求定義應用程序/組件的“范圍”。很少有組織希望每個應用程序的每個組件都在混合云中運行。如果應用程序/組件依賴于只在公共云上可用的Web服務，那么它的主要范圍就是這個云。如果只有在這個云的一些地方才能滿足內部審計合規性規則，那么這些地方就是其范圍。這些范圍必須在部署和連接應用程序的操作軟件中執行，以確保它們只在它們可以/應該在的地方運行。

　　通過工具和政策實施范圍限制并不困難，不需要專門的工具。它確實需要注意云提供商和數據中心環境的具體限制，需要進行一些規劃和審查，但是通過其范圍將應用程序分組是有用的，因為它可以檢測潛在的故障轉移和云爆發問題。組織還將發現，如果可以將專業化的工具和實踐與各種范圍保持一致，那么在集成和管理方面，組織將會更輕松。

　　第三步是將每個可以加載的應用程序/組件與負載平衡功能關聯為前端。必須為工作分配提供可擴展性，因此應用程序集成中使用的工作流連接必須與負載均衡器連接，而不是可擴展組件。負載平衡、應用交付控制、“第3層交換”和其他技術都已用于此任務。

　　在集成混合云的應用程序時，至關重要的是，組織可以在組件擴展期間擁有盡可能少的實現選項，以支持工作流分發，并確保擴展或退出步驟不會斷開工作流或用于數據的不期望的迂回路徑。