[[123432]]

私有云的實施瓶頸往往阻礙了混合云的實施。一個開發運營的思維模式可以讓企業用戶在缺乏私有云承諾的情況下實施混合云。

幾乎 每一家公司都能夠從公共云服務中找到好處，但是他們中的大多數卻無法證明私有云的價值。很多企業已經實現了數據中心的虛擬化，但是似乎他們并沒有看到更進 一步的需要。這些企業在專用服務器上運行關鍵任務應用程序，這也正是這些應用程序最適合被部署的所在?；旌显扑坪跏且粋€可行的解決方案，但是其中的私有云 部分卻仍然是一個障礙。那么，如果一家企業在缺乏私有云實施保障的情況下實施了混合云計算，情況又會如何呢？這是可能的——甚至比你想象的更容易。

混合云實施的一個瓶頸一直就是私有算實施。傳統的混合算就是公共云和私有云的簡單組合，其中缺少了兩者之間的服務流程編制和自動化。但是，一些企業正在使用云友好的集成方法來整合公共云應用程序組件和那些仍部署在數據中心中的組件。而開發運營工具使得這一切成為了可能。

安 裝任何的應用程序，尤其是基于混合云的應用程序，從傳統意義上來說都分為兩個階段，即：部署和集成。在部署階段，應用程序組件的副本被安裝在它們將運行的 服務器上。在集成階段，應用程序組件被互相連接并連接至應用程序的用戶。當你實施云時（無論是公共的還是私有的），部署階段是會變化的，而集成卻是保持不 變。通過讓你的內部部署數據中心資源保持在你的內部，你就可以降低實施混合算的混亂。

開發運營工具節省時日

IT 部門通常都會為應用程序部署選擇靈活的開發運營工具——無論云的內外。諸如Chef和Puppet這樣的工具適合各種各樣的云管理系統，它可允許管理員選 擇***的公共云服務。但是，他們通常都忽略了這一點，即這些工具同時部署和集成了應用程序組件；部署工作是不必在云中實施的。如果使用了開發運營工具，那 么混合云應用程序中的私有云部分是否真的駐留在私有云中就不再那么重要了。

開發運營工具能夠讓企業充分利用公共云的所有好處且不會改變實施私有云的內部IT方法。這樣做有三個好處：
很多關鍵任務的應用程序是很難被遷移至云的（甚至私有云），具體原因有二。其一，相關軟件是為專用服務器應用而設計開發的。其二，應用程序的性能和穩定性 需求是最適合專用服務器和存儲資源的。混合這些應用程序而不把核心組件移至私有云可讓一整組新的應用程序獲得云的好處。
運行在較舊的軟件平臺上的應用程序可能是難以遷往私有云。當這些應用程序能夠簡單地如常運行時，混合云的業務案例就能夠得到提升。

為了運行一個私有云，企業組織需要擁有一些原本并不具備的工具和技能。此外，你的企業可能并不擁有足夠的IT人員或技能來創建一個高效的私有云資源池。通過公共云服務和內部非云組件的混合，就能夠消除這一點。

混合云計算消除私有：如何實現

為了在沒有得到私有云承諾的情況下充分利用好混合云計算，可查看應用程序的工作流程以確定應用程序的哪一個組件可遷往公共云。通常，這些組件是應用程序的前端。所以，你需要為這些應用程序開發云部署實踐。

第 二個步驟就是使用工作流程把應用程序組件部署過程從組件和用戶的集成過程中分離出來。從混合的角度來看，部署的目的就是創建一組可供組件定位的目錄項。同 時，集成的目的就是通過這些目錄項的線程連接來移動數據。不要混淆這兩者是非常重要的，或者當你每次變更你的云供應商或者內部IT平臺時，你將不得不重新 進行一次你的所有應用程序生命周期管理（ALM）過程和工具決策。

混合內部非云組件和公共云服務的***問題在于，在按需或故障轉移場景下實現組件跨云邊界的彈性遷移。出于內部安全性或合規性方面的原因，不要計劃對那些你不允許在公共云中運行的組件實現云托管。以其他的方法處理那些需要內部運行的應用程序組件的可靠性、可用性和可擴展性。

當 你試圖對你的內部部署應用程序組件實施云化時，請務必記得以下原則：在開發運行和ALM實踐中把集成和部署分離開來。組件部署不同于對其托管位置的依賴， 但是如果你確信云和非云部署的流程代表每一個部署組件的目錄項軌跡時集成是相同的。集成僅適用于此；只要云和非云部署都導致產生相同的集成目錄項，那么你 就可以使用相同的方法和工具來執行集成。

原文出自：http://www.searchcloudcomputing.com.cn/showcontent_86391.htm