最高效的混合是利用所有組件的有利優勢。未來的混合云必須利用公有云的新功能，而且能夠保持私有IT投資中的優勢。如果你沒有考慮數據中的混合需求，企業的風險成本就會直線上升、利益實現問題，甚至是完全技術失敗。大多數用戶表示云項目失敗的主要時間是在計劃階段。正確制定項目計劃，才有良好的機會實現成功。
在為了支持混合化設計公有云應用時，有四個因素必須考慮：應用模型、平臺、數據庫訪問以及組件如何連接在一起。
選擇應用模型
在為未來的混合化設計公有云應用時，首要考慮的關鍵因素就是應用模型，不管是前端還是后端模型。企業業務部分報告，他們目前的公有云應用三分之二都是前端模型，在這種模型中云技術加在用戶的當前的應用系統之間。這也是互聯網零售應用最常用的模型。剩下的大部分企業則關注云爆發或者備份了現有系統的故障恢復應用。
如果你正在為混合化開發一個公有云組件，確保調整當前的架構，適應混合的本地端，或者調整現有的架構適應云端。這些都是你需要在計劃階段解決的，因此在應用的最初需求和未來需求上都要認證考慮。優化混合化最必須的是控制公有和私有組件之間的工作流。你需要支持目前的IT時間，但是你也需要開發唯一的彈性和臨時的云屬性。
用平臺創建和諧關系
技術層面的輕松的混合化的基礎就是平臺和諧。一個混合云理論上可以通過任何接口集支持工作流，這個接口可以使公有云支持的，也可以是私有IT支持的。在實踐中，公有云中有不同的操作系統和中間件，會讓事情復雜化，而且變得更加昂貴，尤其是在公有云端的操作支持。
如果你有統一的本地IT架構，就需要認證考慮云端的相同架構。如果你計劃一個云爆發或者故障恢復的混合應用，幾乎強制性的要使用在云端和數據中心相同的操作系統和中間件。甚至是在構建類Web的前端到當前的IT平臺時，要根據性能加強或者隨著備份調整架構的一些可能運行在公有云端的關鍵組件。
讓數據庫訪問公有云和本地IT
在為混合化設計公有云應用時要考慮的第三個問題就是，你如何根據數據需求提供公有云和本地IT資源。存儲關鍵的企業數據到遠端設計成本和安全問題，因此大多數用戶選擇將其數據庫保留在本地。因此，當混合應用的云組件必須訪問數據時，訪問必須跨WAN在云和數據中心之間連接，這樣做也是昂貴和性能密集型的方式。
對于云爆發或者故障恢復應用，更適合的解決方案就是使用查詢服務數據庫管理系統，而不是讓云組件使用標準的磁盤I/O方式訪問數據庫。對于前端應用，可能在當前數據庫創建一個邏輯分離更有價值。比如，一個零售的云前端可能使用來源于標準零售庫存應用的產品分類，但是不包含庫存數量信息；用戶瀏覽靜態分類，但是只在訂單設置時連接到真正的數據庫。
確定應用的“鏈接”
最后的考慮也是最技術的：你的混合應用如何在應用程序接口（API）層面上連接，你的應用如何管理上下文環境或者狀態？在軟件開發中，組件使用API鏈接，這些API也通常定義了組件如何追蹤他們試圖支持的流程。
為混合換開發公有云應用的挑戰在于，大多數企業軟件基于嚴格的面向服務架構（SOA）和簡單對象訪問協議（SOAP）的API。云應用大部分通常采用REST和HTTP架構。不同點在于SOA和SOAP通過多種事務階段鏈接組件，而且所有的組件通過其API自動同步其行為。使用REST或者HTTP時，大多數情況下的客戶端，瀏覽器界面追蹤上下文環境，這個上下文環境明確地通過這個API交付到每一個組件。
實際的差異在于，任何軟件組件的副本訪問恰當的數據庫可以處理任何REST請求，但是SOA-SOAP請求必須通過最初選擇的具體的軟件元素處理。REST架構支持簡單的附在共享和負載均衡，但是SOA-SOAP中就很難實現。這意味著任何可能包含云爆發或者故障恢復的混合架構要認真考慮REST架構。全端應用可以使用應用組件，運行在云端或者本地，來橋接云端REST或者Web友好的架構和更為傳統的數據中心應用架構。
京公網安備 11010502049343號