【思路】混合雲與多雲管理進入架構時代！

混合雲融合了公有云和私有云，是近年來雲端計算的主要模式和發展方向。我們已經知道私企業主要是面向企業使用者，出於安全考慮，企業更願意將資料存放在私有云中，但是同時又希望可以獲得公有云的計算資源，在這種情況下混合雲被越來越多的採用，它將公有云和私有云進行混合和匹配，以獲得最佳的效果，這種個性化的解決方案，達到了既省錢又安全的目的。

　　隨著運維流程變得越來越靈活，IT團隊面臨著越來越大的複雜度。當應用動態改變時，可以使用敏捷或者持續應用開發。但是當IT資源本身動態變化的時候怎麼辦呢?

　　多雲和混合雲是這一新的、動態的IT大格局的一部分——並且帶來了新的風險。要解決這裡的問題，一些企業使用了基礎架構即程式碼方案。

　　配置管理(CM)在大規模IT基礎架構裡一直是必需配置。有一些CM工具，來自於雲供應商，比如AmazonWebServices或者MicrosoftAzure，或者來自於虛擬化或私有云軟體供應商，比如OpenStack或者Vmware。

　　基礎架構即程式碼通過為應用程式建立虛擬託管模型來擴充套件了CM。這樣虛擬的託管模型散佈在多個雲環境和資料中心平臺裡。

　　雖然基礎架構即程式碼是CM的一種擴充套件，它其實是作為DevOps的擴充套件才開始流行起來。使用者無法在還沒有搭建好的伺服器或者雲服務上部署應用程式。因此，DevOps工具和指令碼必須包含這些配置任務。這使得DevOps指令碼和工具是和配置繫結的;如果從一個雲平臺改變到另一個平臺，使用者就必須更改指令碼。基礎架構即服務提供了一種方式，將應用程式的虛擬世界和底層資源，包括雲，隔離開。有更多的託管方案存在，基礎架構即程式碼就會更加有價值。

　　基礎架構即程式碼模型為部署描述建立了中間層;使用者將應用程式部署到基礎架構即程式碼所建立的抽象的託管模型裡，基礎架構即程式碼隨後將其適配到當前使用的任意雲，多雲或者混合配置環境裡。基礎架構的變動在應用程式和運維層是不可見的，並且新增新的雲供應商僅需要在基礎架構即程式碼裡完成其定義即可。

　　但是，基礎架構即程式碼的使用者需要注意如下三大重要步驟：

　　1.將基礎架構即程式碼從DevOps中隔離

　　IT團隊能夠將基礎架構即程式碼部署到定義了配置指令碼的任何環境裡，並且使得應用程式能夠適配幾乎所有公有云服務或者資料中心平臺。

　　IT團隊需要基於哪種基礎架構即程式碼將部署配置，來定義IT資源的抽象模型。基礎架構即程式碼工具和實踐變化很大。一些使用者為每個應用程式都構建了基礎架構即程式碼，而另外的使用者為每種型別的雲託管環境，比如基礎架構即服務，平臺即服務或者Docker，構建通用的模型。

　　總的來說，最好減少建立出的抽象託管模型的數量，因為當新增新的託管選擇時，你必須除錯每個模型。工具允許的情況下，考慮層級構建模型，這樣部署應用元件——或者某個應用的一部分——的基礎架構即程式碼模型，可以在部署整個應用程式的模型裡直接引用。

　　2.為使用的所有云或者資料中心環境保護對基礎架構即程式碼的支援

　　一旦你理解了所需模型，要確保它們能夠支援計劃使用的特定的雲供應商和資料中心的配置。幾乎所有基礎架構即程式碼工具，比如Chef和Puppet，都讓使用者為任何環境定義自己的配置規則，但是流行的公有云，私有云和平臺方案——比如hypervisor，容器系統和伺服器作業系統——都作為基礎架構即程式碼工具集的一部分提供。還可能有社群的支援，其他使用者將他們的配置規則貢獻出來。從已經能夠工作的配置上開始開發，比從頭開始構建自己的要更加容易。

　　3.將事件流從基礎架構推廣到部署工具

　　完成基礎架構即程式碼方案中最微妙，困難和重要的事情是，處理基礎架構即程式碼和其他工具整合的事件流;大多數情況下，這意味著使用DevOps工具。應用程式生命週期運營管理需要根據情況選擇合適的軟體——這些條件就是基礎架構即程式碼裡的事件。這些事件，通過託管資源生成，充當幹什麼事情的訊號。他們通常啟用一個自動化流程，比如通過在別的地方託管來替換髮生故障的應用程式元件。

　　基礎架構即程式碼事件和流程緊密連結，這也是為什麼大多數計劃使用混合或者多雲部署的企業會研究其DevOps工具對基礎架構即程式碼的支援，而並不使用單獨的工具。基礎架構即程式碼和DevOps的整合確保事件觸發流程的正確設計和實現。

　　將基礎架構即程式碼整合進DevOps還能夠幫助使用者避免常識性錯誤。如果已經有了特定的工具，並且如果基礎架構即程式碼整合進了DevOps的話，使用基礎架構即程式碼計劃託管資源就會更為容易。這是因為虛擬化整個部署流程以及基礎架構即程式碼的資源角色會更加容易一些。DevOps工具和包會公佈其支援的公有云服務，如果DevOps工具包含基礎架構即程式碼元件，使用者就知道該工具能夠和列出的公有云一起工作。

　　對於資訊控制、可擴充套件性、突發需求，以及故障轉移需求來說。混合和匹配私有云和公有云是一件好事情。我們已經建立了一些雲端計算模式：私有云，公有云，公眾雲，以及混合雲。根據國家標準和技術研究所的定義，很多企業已經在不同的、更加複雜的方向上適應了這些模式。最近，雲端計算的發展計劃開始圍繞整個架構支援方面，圍繞混合雲，或者是混合、匹配各種雲端計算模式來展開。

　　顧名思義，混合雲，是目標架構中公有云、私有云和/或者公眾雲的結合。由於安全和控制原因，並非所有的企業資訊都能放置在公有云上，這樣大部分已經應用雲端計算的企業將會使用混合雲模式。很多將選擇同時使用公有云和私有云，有一些也會同時建立公眾雲。

　　有趣的是，並不是說私有云和公有云各自為政，而是私有云和公有云同時協調工作。下面是一個經典事例：在私有云裡實現利用儲存、資料庫和服務處理，同時，在無須購買額外硬體的情況下，在需求高峰期充分利用公有云來完成資料處理需求。目前，已經有很多企業都朝著這種集中雲(cloud-bursting)的架構發展，同時這也是實現利益最大化的關鍵。

　　因為公有云只會向你使用的資源收費，所以集中雲將會變成處理需求高峰的一個非常便宜的方式。比如對一些零售商來說，他們的操作需求會隨著假日的到來而劇增，或者是有些業務會有季節性的上揚。

　　同時混合雲也為其他目的的彈性需求提供了一個很好的基礎，比如，災難恢復。這意味著私有云把公有云作為災難轉移的平臺，並在需要的時候去使用它。這是一個極具成本效應的理念。另一個好的理念是，使用公有云作為一個選擇性的平臺，同時選擇其他的公有云作為災難轉移平臺。

　　當然配置方式和這些方式背後的目的是很多。資料顯示，大部分使用雲端計算的企業將會應用幾種混合雲的型別，這其中的很多簡直太複雜了。

　　不管你在IT行業已經待了多久，你都會意識到這些都不新鮮：只不過是把你現有的IT資源重新分佈和整合。不過，在雲架構的選擇上，我們又多了混合雲這樣一個選項。

　　要更加高效，基礎架構即程式碼必須和DevOps緊密合作，但是同時又保持自己的特性。如果不仔細的話，就會開發出界線模糊的配置和部署實踐，並且逐漸侵蝕資源的獨立性——這其實是基礎架構即程式碼的最大優勢所在。在多雲和混合雲的部署裡，維護敏捷基礎架構至關重要，因此這應該成為特定的目標。