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

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

[[130776]]

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

云計算應用的方方面面

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

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

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

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

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

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

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

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

確保高品質的用戶體驗

用戶體驗一致性是所有混合云設計問題中***挑戰性的一個，其部分原因是因為這個問題具有非常強的主觀性和可變性。公共云計算應用體驗特性會有顯著的差異，這一差異性主要取決于用戶相對于其相關云計算托管點的位置，云計算托管相對于數據中心組件的位置以及所有這些位置的網絡連接質量。

通過使用可用性區域的方法來管理托管發生位置，以及通過確保云計算爆發或故障轉移的動態調度過程中不會產生可能在事務性應用的stateful行為中引入延遲的應用錯誤，就可以非常容易地解決混合云應用的應用體驗特性問題(即確保用戶永遠不會離基于云計算的組件太遠)。

混合云應用設計的***一點就是客戶端設備以及托管在其中的任何本地軟件的角色問題。當應用體驗特性比較糟糕時，客戶端軟件可以管理“用戶-應用”的交互以防止用戶通過重新提交申請而產生多個更新。而在發生云計算爆發或故障轉移過程中，它還有助于重新同步應用會話或交易。

如果你在你自己的混合云應用開發過程中遇到過上述的大部分設計問題，那么你可能需要考慮采用一個專業設備應用來配合云計算應用的其余部分。反之，這樣做將提高系統的穩定性和用戶的滿意度。