「混合雲」真的是新型IT服務平台？

現今，混合IT一詞常用於多場地IT橋接的言論里，但這個詞是進行了過分簡化的。如果深入談論所有的混合IT，就需要談論標準化，合規性以及如何將我們的IT方案概念化等一些艱難決策。

作為一個營銷術語--"混合+一切"都是指對先前分離的兩個事物的整合。混合存儲陣列包括快閃記憶體和磁介質。混合WAN網路則是包含了多個連接類型的網路拓撲結構，例如MPLS和一個基於網路的傳輸通道。

可是到了2017年，當我們談論混合IT時，所說的是聯合內部部署IT和公有雲IT。有時我們甚至可能會增加託管IT的服務提供商。不論如何，我們始終都應該了解自己說的混合究竟是哪種形式的混合。

IT已然是混合型

我們給多場地與/或多供應商的IT一個特殊的營銷標籤進行區分。並不是要深究標籤本身，而是我們要把它看作不同的東西來特別考慮。

我們加"混合"這個詞就意味著應該把多場所IT視為一個帶來了巨大變化的新奇事物，尤其是在易用性方面。比如一個PDA，MP3和手機，用智能改變世界，而混合IT將會改變IT的面貌！

然而，混合IT沒啥特別的，它不是你應該考慮做的事。你不需要為此制定長期計劃。事實上，除了個別利基案例，混合IT是你已經在做的事情。

可能你想稱其為多場地IT，多供應商IT或是混合IT。現在我們簡稱為IT。只做內部部署IT或公有雲IT的人比較奇特。而絕大多數使用公有雲，私有雲和服務提供商的組合解決方案的才是常態。

也就是說，混合IT雖然常見但並不意味著它能進行有效地實踐。我們仍要了解很多關於它的方式和方法。

多個通道

IT服務可分為三大類。基礎設施即服務（IaaS），平台即服務（PaaS）和軟體即服務（SaaS）。這三大類是眾所周知的，同時也是公有雲提供商的標準營銷方式。

IaaS沒什麼特殊，一個按鈕控制的接收操作系統。無論在本地，AWS或是服務提供商的雲上，它都只是一個具有操作系統的虛擬機。PaaS需要多一點關注度，但除了幾個版本限制，LAMP伺服器就是LAMP伺服器，無關提供商。

IaaS和PaaS當做一件多供應商事務，很容易能做到。如果腳本需要建立在裸機操作系統或標準化平台之上，那麼哪家能提供最低成本，最低延遲與/或最佳服務就可以選擇哪家。IT基礎設施變成了一件真正的商品。

而SaaS卻不同。傳統上，SaaS是作為類似一份與SaaS開發人員簽訂的合同的存在，並沒有論及他們所使用的平台。例如有人訂閱Dropbox，但不會指定是"谷歌雲平台上的Dropbox"。

但它正在開始變化。較小的供應商正在充分利用公有雲，私有雲和服務提供商雲所提供的市場。比如Salesforce，大到足以讓客戶去忽略它所使用的雲提供商，而記住它在所有主要的公有雲上都提供了服務。

這對於那些想把所有公有雲局限於一家提供商的人而言，是個好消息。SaaS提供商都在整齊劃一，而且緊密集成工作負載可能產生最低延遲而且會形成單一賬單費用。對於那些想要跨多供應商傳輸工作負載的人來說，這也是一個好消息--可能你稍一努力，基礎架構提供商就能夠實現所有工作負載的靈活性。

此外，我們對IaaS或PaaS跨平台功能的依賴性正在減小。

雲代理

IaaS和PaaS本身並不壞。值得一提的是，舊式混合IT一直希望將本地工作負載無變化地向服務提供商或公有雲提供商遷移。而在2016年初被甲骨文收購的Ravello就非常擅長此道。VMware也越來越能夠通過其雲產品來實現這項功能。其它供應商預計將於2017年交付。

這就為雲代理創造了一個市場--第三方會根據你選擇的標準找到運行工作負載的最佳位置。這些標準可以是價格，延遲，數據主權，數據位置，監管認證等。

隨著供應商的價格和功能的變化，雲代理商將會建議客戶遷移工作負載。根據云代理商的軟體與客戶基礎設施的深入融合程度，可能就會觸發客戶的工作負載遷移。

當然,我們也可以將虛擬雲代理構建成一個軟體。這可能會出現在客戶的場地或是一個客戶控制的託管實例里。它可以讀取公開的數據，或從虛擬雲代理軟體處接收更新。雖然對於客戶而言，能控制工作負載是非常好的，但可能並非最佳方案。

更直接控制客戶工作負載位置的雲代理商能夠代表客戶進行議價。雖然政府或全球五百強企業或許能夠從服務提供商或公有雲提供商那裡拿到折扣或優惠，可中小型企業就懸了。

因此雲代理商倡導成千上萬的小型企業從各大規模的供應商那裡拿到優惠。一些新一代"工作負載代理商"正在尋求獲得異地託管型服務和內部部署基礎設施的議價權力。

在超大規模提供商的世界裡，捆綁才是硬道理。SaaS應用程序開始在多個平台上可用，這一點正在填補這個方案里的最後一個漏洞。消除平台排它性，將權力重新放回客戶手中，而不是交給託管基礎架構提供商。

標準化需求

將工作負載從A處輕鬆遷移到B處的能力是正確打開多場地IT遊戲的首要"姿勢"。作為最低限度，你需要一種從一個地方遷移到另一個地方獲得數據和配置的方法。

這就有了關於標準的討論。考慮一下遷移IaaS工作負載需要什麼。最簡單的方法是只將虛擬機從A地遷移到B，但這並不總是可行或者很容易。因此通常大家都是在目標基礎架構上重建工作負載而非遷移。這種處理方式取決於相關的工作負載是基於模板還是基於管理程序。

基於管理程序的工作負載就是在一個空白的虛擬機里放入操作系統和代理。代理與主伺服器協同查看應有的配置，安裝相關應用程序，附加數據存儲並應用這些配置。一切都是腳本化和自動化的。然而，如果基於程序的工作負載，每個提供商都需要一個常見的基礎設施管理程序。

模板更為傳統。就是你策劃並建立一個模型。然後對這個模型進行複製和普及，可能運行一些克隆後的腳本會讓定製化變得更容易。通常在工作負載準備好之前，需要手動干預才能完成任務。一些模板方法在最後階段使用更類似於管理程序的方式消除手動干預。

標準化的促進作用

PaaS嘗試通過消除對整個操作系統的需求來解決這一問題。但能否成功再次取決於標準化;不同供應商的PaaS產品是否也是如此呢？

SaaS應該能在不同提供商之間"正常運行"，但通常行不通。例如，線上QuickBooks和本地QuickBooks的功能之間差距巨大。一些供應商只是有不同的團隊在不同的平台上設計不同的解決方案，並且隨著時間的推移，這些產品會有分化。

連鎖反應

除了原始工作負載兼容性和實施標準化之外，我們還需要規範治理。但由於不同的提供商具有不同的管理，監控和警報方法，問題可能會比較棘手。例如，在本地你可能要有加密所有工作負載的能力，但你需要依賴於公有雲中每種工作負載的加密解決方案，並採用完全不同的密鑰管理方法。

由於多場地和多供應商IT擴大了企業內部部署的覆蓋範圍，IT治理從僅需要擔心工作負載在線與其功能而轉向追蹤工作負載的放置位置，數據保護和隱私影響包括其他風險和合規性的問題。

就像累積更新一樣，通過更新消除大量控制，提高阻斷第三方應用程序更新的可能性，而無需修復。API也是一個弱點。現在，提供商API更改可能會影響企業的大量工作負載，嚴重破壞應用程序集成甚至破壞加密。

適應性

如今混合IT是我們正在做的。最終，隨著時間的推移而提高工作負載位置的多元化。

而通常為了最大限度地降低風險，提高效率，我們不得不開始與第三方合作，在我們的內部IT部門和業務部門之間提供一層"粘合劑"。這些第三方提供商可能是雲代理商，增強了我們的議價能力，並獲得一個更合算的價格。

這些第三方提供商也可能是更傳統的諮詢公司或渠道合作夥伴，和原來一樣幫助我們--了解如何將所有這些技術結合在一起。只是現在有了更多的雲和API，比以往增加了更多的不確定性。