私有云是進入混合云的***跳板。企業要從私有云模型遷移到混合云需要設定具體的目標。

當企業開始利用服務器虛擬化來提高效率和降低成本，許多公司會很快發現他們正在支持的看起來更像是云計算而不是虛擬化。這些相同的公司中大多數已經使用了公有云資源，他們需要一種新的基于所有資源和數據元素混合化的IT模型。要擴展私有云模型到新的混合數據和處理模型，用戶應該建立一個對資源透明的目標，針對這個目標協調數據模型，API和開發實踐，使用設計模式來協調應用特定的需求和工具。

[[129721]]

虛擬化技術演化為云計算的方式論證了為什么在特定的技術上構建IT規劃是有風險的。一個更好的方法是建立在技術透明的基礎上，也就是側重于對服務器和數據資源的抽象化。然后開發人員可以將這些抽象對應到某個特定的方法，而那個方法可以不斷進化，因為隨著時間的遷移，資源成本和需要都會發生改變。

私有云用戶有一大優勢，因為他們的內部IT早就已經建立在云的抽象基礎上。私有云拓展所需要的一切就是讓IT將現有的私有云管理API映射到合適的公有云服務。在許多情況下，私有云規劃包括了選擇一個云管理系統，其API是和公有云API兼容的或者是公有云選項在私有云API上得到支持的系統。

托管資源透明度的關鍵需求是基于策略的資源選擇，根據成本，可用性等選擇公有云和私有云的邊界。如果這種能力沒有包含在初始的私有云工具集里，IT將不得不考慮增加這一功能。來自HP、IBM、Oracle和微軟公司的云工具多半會提供這些功能，但是他們也許會以附加軟件包的方式收取額外的費用。

在數據資源方面，透明度的目標是通過識別現今存在的兩種獨立形式的“數據動態性”。一個是數據的持久性，是否基于實時事務而改變或者以靜態意義的方式從歷史數據或固定數據庫導出。另一個就是數據是否能被動態展示，意味著你可以自動的從數據視圖構建網頁。

持久化應該是對任何數據庫都明確的數據屬性，因為持久化的數據可以被更容易的跨云遷移或者被復制來提高使用該數據的分布式組件的性能。數據的動態展示對于暴露數據而不需要撰寫自定義的應用來說很有用，自定義應用可能會假設一個特定的數據庫位置或者訪問級別。開發者應該試圖在擴展他們的私有云模型上將這兩種形式***化。

API和應用生命周期管理現在必須要做到***的透明度。舉個例子，需要完全在一個混合云中的公有云部分或之外進行維護的應用程序組件需要被分組為一個虛擬組件并且托管策略之后要加強所需的配置。這也允許開發者在生命周期管理（ALM）的過程中可以正確的測試組件。在某些狀況下，這可能需要創建一個façade API來代表一個虛擬組件，這樣組件的構成可以隨著時間改變，如果需要做一些開發來讓資源可以更加靈活的使用。你還可以使用API來提供對于應用來說統一的持久化和非持久化數據的訪問。在某些情況下，這些新的虛擬數據模型也可以驅動網頁的動態數據生成用于訪問和更新。

在數據端的具體策略是確保應用對持久化和非持久化混合數據的訪問是被仔細管理的。將應用組件化，這樣對事務性或者動態數據的訪問會被限制到盡可能少的組件中，因為需要實時數據的組件將可能更難分配為有效的操作。開發人員要對組件中的持久化和非持久化的混合數據API進行仔細管理。

當低層次的API沒有提供所有控件開發人員所想要的東西時，使用設計模式（比如外觀模式）是一種強大而靈活的方式可以資源透明化。比如，一個被托管在某處的應用程序組件需要訪問自己的數據。如果該數據是靜態和動態的混合，那么請根據類型上將數據分隔開。如果這個應用組件被移到公有云，請將數據同組件一起移過去這樣以便訪問。這種抽象數據訪問的方法可以幫助組件封裝資源的具體細節，這對于開發人員不想要綁定某個托管選項時是很必要的。

如果有必要將云爆炸或者故障轉移構建到已有的應用中，設計模式在確保橫向擴展和負載均衡分配的一致性的過程中很重要。經驗表明試圖在每應用的基礎上，以資源透明的方式開發會產生各種各樣的方案，測試和驗證所有這些方法會很頭痛。如果每個組件在資源使用上都各行其道，要管理應用到資源的關系也會困難很多。也許需要很多前期的工作來將應用改成用新的設計模式而不是老的API，它可能會從降低ALM和運營的成本并提高資源的敏捷性上迅速得到回報。

云，不管是公有、私有或者混合，都不是最終的目標。真正的目標是獨立于資源的應用組件托管。隨著云應用從簡單的未充分利用的服務器遷移到云進化到特定云的開發，優化平衡私有IT云和公共云所產生的益處將會增加。利用通過新的API和應用模型所產生的透明度的機會也會增加，開發人員和架構師們從私有云到混合云的轉變中所學到的將為他們做好迎接IT未來的準備。

原文鏈接：http://www.searchcloudcomputing.com.cn/showcontent_88194.htm