雖然大多數CIO喜歡混合云方案，但現實卻悄悄遇到了點煩人的小問題——如受美國和歐盟的一些電信業務光纖連接投資不足所累。歡迎來到云爆發架構的地獄式網絡體驗。
缺乏公有云與私有云之間的帶寬使得云爆發與敏捷需要重新定位IT工作負載的理論概念。此外在云爆發架構中遷移數據與系統配置的成本與在局域網（LAN）帶寬和存儲訪問相比，要大得多。
這個與網絡資源有關的問題導致了NetApp和Verizon兩家公司，成立了合資企業以合作將用戶數據傳輸到Verizon數據中心，以加快公有云的訪問。這個問題也是希望采用云爆發的企業需要面對：將外部數據傳輸到內部混合云中。從本質上講，帶寬問題依然存在，但現在問題在混合云的本地私有部分，而不是云提供商。
有四種方法可以解決云爆發中可能遇到的問題。
拋棄混合云——轉向公有云
公司IT運行的一切都可以遷移到公共云。有人會祭出塞班斯-奧克利斯法案和健康保險流通與責任法案，這些都不是簡單的問題。主機托管在某種程度上是可以接受的，因為這意味著你擁有IT基礎設施，將其托管在符合規范的建筑內，但公有云是一個整體的、擁有眾多租戶的猛獸。在2016年，我們可以看到Amazon Web Services（AWS）和其他云服務提供商提供了專用系統以及簽訂長期合同兩種方案，有效的創造了滿足規范要求的能力。
托管式云服務提供了必要的云爆發架構，再加上快速的存儲訪問，可以讓云真正靈活。該機制擁有長期性，還能保證所需配置的穩定性以企業數據與系統訪問的絕對安全，同時保證靈活性以及在大爆發時的能力。
獲取快速WAN
另外一個選擇是通過電信運營商的快速廣域網鏈接混合云的私有部分和托管部分。這樣可以讓普通負載使用快速LAN，采用高速光纖鏈接大規模公有云，實現云爆發或者工作負載重新平衡，這樣遠比實現一個內部云要好得多。
從內部爆發
另一個潛在的云爆發架構是在自己數據中心內，部署所有的一切。內部云爆發可能需要仔細的調度以及頻繁的重新平衡，但這個還不是非常完善的自動化過程，所以不容易實現。
建立一堵墻
另外一種方式是對數據進行分區，是部分子集永遠留在公有云。如果數據是暫時性的，就如某些大數據類，以及公有云與私有云之間的邊界可能是動態的情況，可以考慮這樣的架構。例如，來自零售商店的傳感器數據流集，可以在到達云分析平臺之前先通過用戶名進行排序，接著根據初始姓名動態拆分。
選擇適合企業IT組織的架構
在所有種種討論中，雖然首先要面對經濟問題。公有云是否比內部云便宜？托管可以節約開支嗎？這些問題遠比單純的價格問題要復雜。在自己的數據中心、托管機房或公有云之間遷移工作負載，任何解決方案都會影響到動態性能，所以IT希望在一個較穩定的環境下運作，而不是從一處切換到另外一處。
安全性也是一個問題，盡管公有云提供商如AWS在反威脅和租戶隔離措施上已經投入了大量資金。一般情況下，討論會從工作負載是否可接受外包，轉移到關于安全的一些流言與成見上。
成本是接下來的問題。運行時間因素的復雜性會處于成本考慮。存儲反問效率、虛擬實例性能以及其他運行相關的因素——這些計算會影響到IT經理判斷。如果實現了在公共云上購買專用服務器/實例，應該可以直接模仿實例甚至內部服務器的配置。最大的問題可能來自訪問存儲的速度。因為內部可能會更快，因為數據流可以在某種程度上進行調優。公有云內的專用系統可能會接近于內部服務器性能。訪問傳統托管設施到第三方供應商的速度，就如本地內部操作一樣快，但公有云的爆發可能會造成一定的延時。
任何托管方案的遷移都需要長期承諾額。典型的合作合同會鎖定IT組織供應商1至2年——這是一個關鍵決策。盡管結果有可能是云服務，但買方喪失了貨比三家，獲得優勢的權利。托管設施供應商的上行鏈路質量是影響云爆發的另外一個因素。質量遠比多元化選擇重要，托管商可能擁有多個上行鏈路選項來連接不同數據中心。此外，因變更、遷移與復制數據造成的中斷；變更工作流與流程；以及審計治理等都是任何云爆發架構財務模型所需的要素。
電信運營商必須開始拖延已久的城市光纖連接鋪設，即使是為了那些受累已久的需要云爆發的IT公司。混合云將很可能以托管服務器的形式存在于云中，或者完全成為托管設置，只要網絡帶寬的問題能得到解決。
想重新回到自建數據中心，幾乎是不太可能的事情了。
并非所有關于云計算的討論都考慮混合結構。是有可能將所有IT工作負載都遷移到公有云或者全私有云的架構中，許多IT機構目前都在這樣運作。云爆發的敏捷性與服務器容量規劃要求可能會提高成本，但其依舊是少數不接受混合云的大規模云計算用戶可接受的模式。
京公網安備 11010502049343號