理論上，云爆發是應對資源需求突然增加問題的理想解決方案。但是許多企業的當前架構或者兼容性并不能保證這種方式正常工作。
對于云爆發架構來說，企業在私有云或者數據中心中運行應用，如果出現計算需求突然增加的情況，那么該應用將會被轉移到公有云中。
理論上，云爆發能夠幫助企業臨時將本地負載遷移到公有云中，因此這種架構能夠幫助企業解決資源需求突然增長的問題，情況穩定下來之后再恢復原狀——這是一種響應快、效率高的IT基礎架構。
但是想要實現負載的無縫遷移并不容易。對于某些企業來說，甚至是不可能的，因為它們的基礎架構存在缺陷。
企業還需要考慮私有云——或者傳統的本地系統——和公有云提供商之間的兼容性。企業經常需要面對由于兼容性問題導致云爆發架構無法正常工作的情況。
基礎架構差異事實上，云爆發所需要的自動化程度很高。并且在許多情況下，企業數據中心的底層基礎架構和公有云的底層基礎架構存在很多基礎性差異。
為了解決這些問題，一些技術廠商為企業提供了能夠在本地使用的公有云特性，比如微軟推出了Azure Stack，這是一種私有云服務，而Oracle也推出了類似的產品Oracle Could Machine。
VMware用戶想要在公有云使用和本地數據中心相同的虛擬化基礎架構。確實，用戶現在能夠在AWS和IBM SoftLayer中運行VMware軟件，但是盡管這些云產品和VMware能夠兼容，但并不是一種高性價比的解決方案。管理員必須從成本方面考慮是在云中運行VMware軟件，還是將數據中心的現有硬件資源重新分配。微軟和Oracle用戶也存在類似問題。換句話說，云爆發所帶來的問題和額外開銷是否值得？
其他阻礙云爆發發展的問題還包括私有云和公有云之間缺乏底層兼容性。由于云爆發的這些潛在風險，許多IT專家認為這并不是一種切合實際的解決方案。相反，他們可能會傾向于混合云架構，尋求本地和云基礎架構之間的兼容性。
管理員還必須考慮缺乏特性兼容性的問題。在過去的幾年，諸如AWS這樣的公有云已經超過了所有私有云產品。如果企業想要使用parity特性，那么是無法在AWS和私有云之間實現的，兩種云之間無法為這種特性提供兼容性，因此當需求超出現有計算能力時，云爆發并不是一種切合實際的解決方案。
現實情況現在企業面臨的最大問題在于：是否需要私有云或者傳統基礎架構？為什么不推動公有云快速發展，使得云爆發變為可能？
一些現實因素包括：
私有云——以及傳統基礎架構——通常性價比并不高，因為企業必須購買和管理硬件以及軟件。對于大部分堅持使用本地基礎架構的企業來說，他們需要的是控制權限，不只是處于安全方面的考慮。威脅活動的變化使得基礎架構的物理位置變得并不像之前那么重要。任何能夠從外部訪問的系統遭受攻擊的可能性都是相同的——不論是企業還是云——因為本質上攻擊都是隨機的。并且公有云通常不會受到普通漏洞的影響。
云兼容性非常差。如果私有云廠商和公有云服務提供商之間不進行緊密合作，那么很難實現不同種類云之間的兼容性——盡管也存在Azure Stack和Oracle Machine這些例外。
“糾結于”部署模型會讓事情變得更加復雜并且產生更多開銷。這些問題并不會表現在PPT上，但是在現實世界，這些錯綜復雜的混合云關系非常難以部署，更加難以操作。即便企業能夠使用云爆發將應用轉移到公有云中，但是這個過程中節省的費用也會被花費在聘請其他員工維護整個架構方面。
即便我們不愿意相信，但是大多數情況下，云爆發架構還是過于復雜和昂貴了。對于大多數企業來說其并沒有任何實際意義。這個結論可能會讓很多人回想起2009年，那時候云爆發還只是出現在云計算的演講中。而現在，情況依然如此。
京公網安備 11010502049343號