破譯雲計算的7個神話

什麼是“雲”？最近一段從來沒有一種技術能讓大家如此熱情，狂熱，困惑甚至於誤解。 Serdar開篇就對雲做了以下概括：

雲不是一個神奇的萬靈藥也不是一個災難，更不是救世主也不是罪人。它是一個解決問題的新工具。

1.兼容性相關：雲計算太專有了

對於這個話題，Serdar的觀點是：

當下，沒有兩個雲是一樣的，無論是本質還是IT。 亞馬遜的雲平台和Google、微軟的都不同，跟即將推出的雲也不一樣。“專有”並不意味著“無用”——決不。

儘管隨著時代的發展，人們對兼容性要求越來越高。 但是：

第一批雲平台的專有性是個不得不存在的特性，但當你使用特定的平台（Amazon.com，Google的Python語言）時，也許這並不是什麼問題。

而且像其他IT技術一樣，隨著雲平台的發展，更多通用標準將會逐步建立起來，目前已經有一些組織開始行動了。

2.隱私相關 ：雲計算是私密性的終結者

Serdar繼續補充道：

對雲平台私密性的擔心可以被看作一個隱私相關考慮的副作用，雲計算只是一個替罪羊……雲計算如此的成為一個被隱私保護者所強烈關注的目標的原因不只是因為它是一種新技術，因為每種新技術都可能被懷疑隱私泄露,更多的是由於在表面看來，它是多個IT領域交匯的產物。當你在同一個屋檐下放置了有很多不同的事物時，這可能意味著“單點故障”的存在或“把所有雞蛋放在一個籃子里”。

而且一旦你的數據和別人放在一起，安全性就不再是你能控制了的：

不僅大多數數據泄露來自於內部組織而不是外部攻擊，而且更糟糕的是，把自己的數據存在別人的系統里並沒有相關的法律保護。

對於這個問題，Serdar認為：

雲計算廠商需要更加主動地面對這件事情，他們應該不惜代價地讓他們的客戶清楚這種情況而且延時到客戶的客戶，他們的數據和處理安全能夠杜絕外部攻擊和內部偷竊，而且他們敢於面對法律。 給用戶數據提供安全保護實際上並不是最難的事情，有很多例子說明這個應該怎麼實現。比如Mozy，在線備份服務提供商通過讓客戶提供他自己的高級密碼解決了私密性問題，Mozy的備份數據不能被任何其他人讀取，包括Mozy自己……

3. 可靠性：雲計算不可靠

Serdar認為

這就類似於這種斷言：“如果沒能證明無罪就是有罪的”。 雲計算的可靠性已經受到質疑。 最近T-Mobile的Sidekick服務的崩潰以及丟失大量用戶數據的事件受到了來自各個方面的批評，大部分是針對理論上的雲的。這件事有個好的結果——每個人的數據似乎都恢復了——但是還有誰有耐心再來一次這樣的經歷嗎？……人們記住你僅有的一次失誤的可能性會遠遠多於你500天不出問題的升級。

他進一步提出：

雲的最大脆弱之處不是在線運行時間，而是數據保護。如果沒有其他的處理，它意味著只有一種數據保護——無論是終端用戶還是備份服務提供商來說都是不夠的。 從單個磁碟鏡像到健壯的文件系統，乃至不同的遠程備份，雲需要多個中心級別的數據保護，並且支持數據移植作為另外一種備份方式。

4. 可移植性 ：雲計算是一個單行道

這話聽起來很奇怪， 實際上它指的是雲數據的導入導出：

不幸的是，對雲的抱怨也是一個不爭的事實，一旦你把東西（服務，數據）移入雲之後，再將它移除來就非常繁瑣了。這些抱怨主要來自那些把他們的數據放到基於雲的服務之後，發現想要退出時只有非常有限的選擇……任何人在建立基於雲系統的業務時需要必須馬上考慮用戶數據如何移入移出雲平台的問題。

而且進一步來講，

數據移出不只是數據格式，一個客戶也可能要把它自己的數據導入到某些物理載體--磁帶，硬碟等。 這些如移出數據等的成本是不是被假定為客戶，提供商，或者兩者同時負擔可以再討論。

但是要讓所人都清楚，客戶選擇雲的時候不是結果發現走了一條走不通的死路。 提供商不能壓迫客戶，而是為他們提供服務的。

5. 大事件 ：雲計算只是虛擬計算的另外一個名字。它不是什麼新東西。

第一次接觸雲計算的時候，都會忍不住想知道它和如網格計算，分散式計算，虛擬計算等技術的不同。

這樣的質疑可能是出於不了解雲是做什麼的而產生的， 雲並非僅是假想的虛擬計算環境——它們除了使用虛擬計算之外還有很多其他技術來完成單個電腦無法完成的工作。

這些困惑可能來自於特定的提供商向開發者介紹雲的方式。比如：

亞馬遜EC2的例子被描述為一個類似於有固定內存，存儲和計算能力的真實的系統。 這樣做的原因很簡單：當下讓開發者領會使用雲的方式 最好就是讓他們認為和他們已經熟悉的硬體差不多。

6. 網路和存儲限制 ：雲計算太受限於網路或存儲以至於用處不大

對於Web開發來說，這兩個資源至關重要個，但這句話並不全對。 因為：

……這完全取決於你在雲上有多大的規模和範圍、I/O的限制、過程是否可伸縮以及你所選的實現方式。 總體來說， 雲的I/O 仍然是個主要的瓶頸，除非我們的連接達到T級光纖。 否則我們要把必須做的工作放到程序端，這對計算能力和程序都有一定的挑戰性，但是更靈活……

數據增長的比網路和帶寬的增長還要快，我們可能要在多台伺服器間同步千兆兆位元組數據，試想如果網路速度跟不上，那些所謂的服務的正常運行都無法支持。 除了增加物理的帶寬，作者也建議：

通過現有網路的改造或者使用類似於適用低帶寬的文件系統，當然這要由你自己來做。其他更多方面要關注如何更有效的利用網路和哪種客戶端更適合於與雲進行搭配。

7. 可伸縮性 ：雲的可伸縮性很難用。

程序員可能有這樣的抱怨，

雲計算很難支持提高效率的編程，他很容易讓一些程序運行起來，但是要是想更容易伸縮那可能是另外一回事了。比如Twitter開始用的ROR，但現在不得不在一點點用Scala重寫。

這些遇到的問題大多是由於并行編程還比較新，對可伸縮性的支持還不是特別全面，但除了程序本身，我們可以考慮從其他方面來解決，如：

Apache的Hadoop，Google的MapReduce等用來訪問和統計海量數據的技術，都可以支持數據分佈在不同的節點上，進而通過不同節點的分別計算並獲得最終的結果。但不幸的是，MapReduce 只對特定的操作有效，不是一個全能的解決方案。所以有的時候問題不得不需要改造來適合已有的解決方案。

作者最後總結道：

關於雲的神話，宣傳，困難和希望是同時存在的。任何人參與雲計算的人都應該團結一致堅持到底！

沒錯，和任何新技術的產生，發展，成熟的過程一樣，有苦也有樂。無論是創建雲還是使用雲，都需要我們不斷地參與，反饋，直至改善它的方方面面，才能讓雲技術不斷的成熟壯大。