雖然為混合云部署開發應用并不是某種黑暗魔法，但是對于很多企業來說，這還是一項具有一定神秘性的工作。

　　可以想象，任何設想進行混合云開發的用戶最終都需要完成很多個這樣的項目，所以首先制定一個可以應用于所有項目的實施策略，然后在一個合適的混合部署中測試這個實施策略將是十分明智的做法。為了實現成功的混合云實施，這樣的一個實施策略必須考慮混合云應用的任務，使用混合云的緣由，以及混合運行與應用體驗特質(qoe)之間的重要相互作用。

　　云計算應用規劃者可能犯下的最嚴重錯誤就是，在考慮綜合、集成或者云計算平臺選擇這樣的技術問題時不為應用本身設定一個應用環境。應用的設計始終主要是由任務而非技術推動的，但是項目任務書則必須正確地綜合考慮業務問題和技術要求兩方面的因素。

　　云計算應用的方方面面

　　應用是可以實現多維度分類的。它們可以是事務性的，或者涉及信息傳遞(第一維)。它們可以是移動的，而不是基于桌面系統的(第二維)。最后，它們也都可以是基于會話或者基于實例的(第三維)。在所有這些維度中，第一個選項要比第二個選項需要更多的設計關注。

　　在第一個維度中，事務性應用的功能是那些記錄或修改信息，這就意味著它們必須在與相關數據進行交互時具有較高可靠性，以避免造成數據損壞的危險。提高可靠性的要求意味著混合應用的公共云計算組件必須具有較高的可靠性，或者必須采取特殊的編程措施(例如分兩個階段提交數據)以保護數據的完整性。如果你將在云計算爆發或故障轉移應用中使用混合云，那么事務性應用就需要在任何規模改變或故障轉移活動期間維護數據的完整性。

　　相反，信息傳遞應用可容忍故障或響應時間變化;如果第一次請求丟失，那么用戶將需要重復提交一次請求信息。這就意味著，諸如負載平衡這樣的簡單技術將支持應用的彈性縮放以及工作任務在公共云計算與數據中心之間的轉移。

　　在第二個維度，移動性會在兩個方面帶來需要特別關注的問題。第一，移動連接是通過無線網絡建立起來的，因此其連接可靠性通常要比桌面系統的連接可靠性更低。這一點將加劇事務性應用中數據完整性問題的惡化。移動用戶也可能是在多個可變的環境中工作的，而公共云計算服務可能是由一個單一的數據中心提供的，這樣一來就會帶來明顯的性能差異。如果用戶的分散度較高，那么就需要尋找區域托管的服務供應商。

　　基于會話或基于實例的應用的問題(第三維度)是指用戶是否會與應用進行長期的多步驟交互，而不是短期的單次交互。協作是基于會話交互的一個示例，而簡單處理一次信用卡購買的業務就是基于實例應用的一個例子。

　　在應用設計中有一種趨勢，即面向會話的應用會通過一個所謂的stateful行為依賴于一個可靠的一致性連接。大部分面向實例的應用(例如網絡應用)是無需維護與一個用戶的多階段對話的環境的(這些被稱為representational狀態轉移或 stateful應用)。綜合stateful應用要困難得多，因為如果一個組件發生云計算爆發或云計算故障轉移，應用就會丟失一個進程中用戶活動的相關信息。

　　可以實施綜合的原因可以是因為動態組件調度或前后端現有的云計算組件應用。動態調度意味著在云計算或在數據中心內根據工作負載或者是否有資源失敗的實際情況把資源分配給應用組件。

　　前后端混合應用會在用戶和應用的其余部分之間開發一個類似于網絡的應用體驗，充分利用公共云計算的優勢來擴展這些組件或者根據用戶的實際物理位置分布把這些組件移動到相應的地域。前后端的方法創造了綜合的一個一致性模式，即組件總是在云計算中或在數據中心內，從而簡化了設計難度。當需要動態地移動組件時，就會實施所有可以確保用戶體驗一致性和數據庫完整性的措施。