雲應用在設計上必須與過去有所不同

編者注：此文是 Eucalyptus Systems CEO Marten Mickos 的文章。

軟體自出現以來模式就未曾改變：運行應用，然後應用則是在平臺上面跑的。 但是由於基礎設施的飛躍發展，應用設計和部署的基礎原則的確會不時改變—有時候這種變化還很激烈。

比方說，1980 年代出現 PC、x86 架構的出現以及客戶機 / 伺服器模式的誕生令應用應用設計原則發生了巨大的改變。 然後，隨著 web 和開源技術在 1990 年代中期的出現又再次劇變。 每每發生這種巨變，開發者都被迫要對軟體的開發和部署方式進行反思。

現在的基礎設施能力又有了新的飛躍，其主導是 Amazon Web Services（尤其在網路速度有了飛躍提升的前提下）。 顯然，為了能夠充分利用新的雲設施，那些在 AWS 上取得成功的應用必須與運行在企業伺服器上的應用有著本質的不同—哪怕是與運行在虛擬伺服器上的應用也不一樣。 除此以外，還有其他一些因素決定了雲應用在設計上必須與過去有所不同。 以下列舉的就是其中一些關鍵因素，這些因素也決定了新舊世界演變的方式：

伸縮性

舊世界的伸縮是通過擴容實現的—要想容納更多的使用者或資料，只需購買更大對的伺服器。

而在新世界裡，伸縮性通常是通過橫向擴展實現的。 要增加的不是更大的機器，而是同類的多台機器。 在雲世界中，那些機器是虛擬機器。

彈性

以前，軟體是不可靠的，彈性是在硬體層實現的。

今天，底層的基礎設施硬體被視為是薄弱環節，所以應用必須自我調整來適應。 應用並不會保證每一個虛擬機器實例都工作正常。 單台虛擬機器一段時間失效也沒關係，應用必須對此做好準備。

就拿 Netflix 來說吧，這可以說是最先進的雲使用者了，它在雲應用的道路上邁出的步伐是最遠的。 他們有一個過程叫做 ChaosMonkey，會隨機地殺死應用負載下的虛擬機器實例。 這麼做的目的是什麼呢？ 就是為了確保應用的正常運轉和彈性：通過讓應用面對隨機的實例損失來迫使應用開發者開發出更加彈性的應用。

爆發性

在舊世界裡，像財務和工資單這樣的應用其負載一般都是很穩定和可預測的。 特定時刻的系統使用者數、待處理記錄數基本上都是已知的。

在新世界裡，工作負載是多變的、不可預知的。 今天的軟體系統的觸角必須伸得更遠，要到達有服務需求的消費者和設備那裡，時間不可預測，負載無法衡量（想想看那個成為眾矢之的的 12306 網站吧）。 要想適應獨立應用負載這些不可預見的波動需要新的架構。 雖然我們現在已經在雲上面了，但是顯然還處在初級階段。

軟體多樣性

在過去，軟體並沒有太多的多樣性。 每一款應用都是用一種語言編寫的，使用的是一種資料庫。 公司一般都是依託與一個或少數幾個作業系統。 軟體棧簡單到令人乏味的地步（至少從現在看是這樣的）。

而在雲的新世界裡，情況截然不同。 一個應用裡面可能就會用到許多不同的語言，不同的庫，不同的工具組以及不同的資料庫產品。 同時由於在雲端時你能夠創建和啟動自己的鏡像，根據特定需求進行定制，一家公司的應用必須能夠運行在各種不同的配置上。

從虛機到雲

哪怕是相對較新的 hypervisor 和現代的雲思維方式之間也是有區別的。 虛擬化的的先鋒和領袖 VMware 所開發的 hypervisor 表現基本上與物理機器並無二致。

而在雲端，虛擬的並不是物理伺服器的代表，而是計算單元的代表。

使用者的耐性

在舊世界，使用者受到的教育是要有耐心。 因為系統的回應可能需要很長一段時間才能完成一些簡單的提取或更新要求，新功能的添加也很緩慢。

在新世界裡，使用者是沒有耐心的。 他們幾乎無法容忍時延，不願意等待。 他們希望軟體經常更新，如果說不是每天的話，起碼也是每週。 你可以在自服務 IT 找到相關證據。 在那裡，你不是遞張條子給 IT 部門然後等待幾天後回應了事，使用者所需的資源可以實現自提供。

(責任編輯：蒙遺善)