云革命已經持續了足夠長的時間了，以至于每一個IT領導者都清楚什么才是最重要的價值主張：云計算可以更容易地共享資源，它能夠快速適應不斷變化的負載和需求，并通過消除購買、安裝和維護自己的硬件機架的需要，來節省時間和金錢。

 

但它也有缺點，而且也沒有被經常提及。也許這是因為把你的煩惱轉移到某個隱藏在天空中的香格里拉般的服務器農場的想法總是如此誘人。

 

不過，將工作負載轉移到云上的真正擔憂并不是那些常見的弊病。是的，云計算機器也會遇到許多同樣的問題，這些問題會使您自己的數據中心中的框架變得混亂。如果Ubuntu 18.04有后門，它就會讓黑客進來，不管它是安裝在云機器上還是大廳壁櫥里的服務器上。所有的計算機都容易受到電源故障、硬盤崩潰、α射線、惡意軟件等更糟糕的情況的影響。

 

然而，更有趣的是云模型所特有的問題。這些問題不會影響您的服務器群中的機器，或者即使它們會產生影響，也不會造成同樣規模的災難。當然，關鍵是要注意并盡可能在以下這10個特定于云的問題再次困擾您之前解決它們。

 

 

當云架構師的需求增加時，云可以自動啟動新機器來處理負載。但當它真的出現時，在那塊幕布后面，儀表將轉得越來越快。

 

這種對負載的彈性響應應該比讓機房里的舊服務器不知所措地崩潰要好。比特被傳送到了他們應該去的地方，工作也完成了。但是，一個超載的本地服務器只會降低所有人的速度或產生一些404錯誤，而在云計算中，您的賬單可能會突然飆升，在幾秒鐘內就把一個月的預算全部抹去。

 

這項挑戰已經淹沒了許多人。最糟糕的情況可能是開發人員在利用云計算來做副業：一次閃電般的打擊，他們就將為一筆巨額的賬單而絞盡腦汁。正因為如此，云提供商為此增加了控制，使您能夠設置預算和請求支出提醒。但這并沒有解決根本的架構問題。一直以來，你的團隊都在重新設計你的應用程序，以兌現云的承諾，而看似無限的可伸縮性也意味著可能無限的賬單。天下沒有免費的午餐。

 

 

在保護數據時，存儲備份會是一個好習慣。但是，如果您的公司的數據是存儲在您自己的RAID陣列上，那么這些數據的成本和容量就會得到控制。相反，當您的數據位于云中的某個位置的一個嵌套的存儲集合中時，就很難知道是否有關鍵的日志文件或數據隱藏在其中了。

 

大多數部署云服務的組織都有保留一切的習慣。為了以防萬一，把每一小片數據都放在身邊似乎是更容易的，但無數小的零頭正在不斷累積，沒有人愿意做出艱難的決定來刪除其中的任何一個。對于儲存在云中的數據進行分類以尋找關鍵的數據位需要大量的勞動。更糟糕的是，數據隱私法規和安全黑客的崛起也意味著，“以防萬一”地將每一位客戶數據塞進無限的云存儲的自由--因為這很容易做到--可能真的會返回來成為你的困擾。

 

當創建一個新的存儲塊變得容易的時候，將來也就更容易產生一個需要來進行排序和保護的麻煩。

 

 

如果一臺機器太小，沒有足夠的內存來運行，你馬上就會知道什么時候軟件會變得很慢或者立即崩潰。但是如果你有太多的內存，就沒有人會抱怨。正因為如此，云計算機器往往會不斷升級，而變得非常浪費。有人會在一個重要的周末之后提高內存分配，而沒有人會抽出時間再去擰緊螺絲，而現在您可能正在為您再也不會需要的開銷在買單。

 

有些團隊會專門安排一個人來觀察參數，但這只會擴大團隊。花錢買幾臺配置過剩的機器，還是花錢請一個新的團隊成員來爭論這些機器，哪個更便宜?

 

 

云提供商的儀表板讓開發者和業務用戶只需點擊幾下鼠標就可以啟動新電腦，這是非常容易的。而且，每小時只有幾分錢，公司肯定負擔得起，對吧?我們不妨在一個干凈的機器集群上測試代碼，您不這么認為嗎?

 

保持云計算的低成本是一項艱巨的挑戰。每個人都明白購買硬件的麻煩。采購訂單，預算會議，運輸延誤。但就像免費的食物或糖果在幾秒鐘內就會消失一樣，幾次快速的點擊同樣也能讓你每月的云賬單增加一倍或兩倍。

 

 

輕負載和休眠機器會讓云計算公司陷入困境。但他們可以將未使用的周期分發給共享相同硬件的其他實例。畢竟，如果它們可以讓另一個客戶滿意，為什么要讓它們閑置呢?

 

但當這些沉睡的機器醒來時，它們會想要回歸自己的硬件份額，而其他機器則可能會開始錯過免費的計算機周期。昨天運行得很快的代碼開始運行得很慢。當然，雖然昨天的高速只是一個秘密的禮物，但也要試著告訴用戶他的工作是進展順利的。

 

 

每個云協議中最容易被忽視的部分之一是數據移動的成本。我們常常把注意力集中在了計算機上，而忘記了比特的流動。

 

在大多數情況下，我們是可以忽略的。一般情況下，平均實例不會超過數據移動的閾值，因此許多開發人員甚至不考慮為查詢提供答案的成本。這一切都很好，直到你的網站像病毒一樣傳播開來的時候，而一個月后驚喜就會出現在你的賬單上。如果您在系統架構方面做得很好，那么緩存將承擔巨大的負載，并且機器也不會陷入困境。然而，云提供商依舊將計算從其系統中流出的字節數，并相應地計費。

 

這是一種難以預料的打擊。聰明的開發人員可能會試圖通過運行許多本地測試機器人來測試負載，這些機器人會不停地ping機器。這可以測試他們的代碼質量，但卻不會標記出可能輸出的高額成本。

 

 

一些公司在大廳里建立了自己的數據中心。其他人甚至買下了整棟樓。在這兩種情況下，每個人都知道他們服務器的物理位置。然而，云計算機器被租借出去時，除了可能找到機器所在的國家或州之外，不會有太多的細節。只要網絡連接速度快，程序員可能并不在乎，但眾所周知，多年來律師們一直就在爭論應該由哪個政治實體來控制。我認識的一家公司在一個沒有銷售稅的州建了一個數據中心，就是為了避免這個問題。

 

很容易丟失數據和應用程序在云中的位置。但大多數人對此并不關心，云提供商也經常出于安全原因故意含糊其辭。但是如果你的團隊中有人關心法律問題，他們就會希望能夠確保你在正確的政治控制下啟動你的實例。

 

 

如果你有你服務器室的鑰匙或者colo機架的鑰匙，機器就是你的了。你控制著一切。然而，云中的實例屬于其他人，他們會自己決定托管在他們身上的東西會發生什么變化。當然，當一切進展順利時，他們通常會順從你，但問題會出現在壓力足夠大的情況下，比如自然災害或戰斗發生的時候。如果一些政府調查人員想要傳喚你的數據，他們甚至可能都不會告訴你的律師。

 

 

服務條款是由云計算公司寫的，除非你開了一張大支票，否則你就無法進行談判。像所有的術語作者一樣，起草術語的人首先想到的是他們自己。

 

考慮AWS服務條款的這一部分：“31.3. 您的郵件域和最終用戶的帳戶可能會被目標電子郵件服務器和我們無法控制的其他原因被阻止、延遲發送。無論你的電子郵件是被阻止、延遲還是屏蔽，你的支付義務都將繼續。”

 

當然，這和大廳里的電子郵件服務器上的問題沒什么不同。即使不起作用，你還是要付錢。但是，如果是一項服務的賬單被凍結了，那就有點讓人驚訝了。

 

 

所有的云服務都會清理掉那些布滿灰塵、發霉的項目，然后把它們扔掉。他們必須這樣做，因為人們總是在試驗云實例，然后忘記了他們的試驗或他們所在的地方。然而，問題是云提供商會按照他們的時間表而不是你的時間表進行清理。

 

例如，AWS承諾會刪除在過去三個月內未調用的所有Lambda函數。如果你的團隊構建了AWS Lambda函數，然后不管出于什么原因把它們放在了次要位置，你就必須記住這個最后期限，并留意任何警告您有人將要進行清理的電子郵件。

 

版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。