抉擇：我的Web應(yīng)用該在哪種云服務(wù)上運行？
當(dāng)開發(fā)了一個web應(yīng)用，或者準(zhǔn)備搭建一個網(wǎng)站，肯定要面對的一個問題是選擇一個服務(wù)器。
這里先不討論上個“時代”的玩法：虛擬主機、VPS。
今天我們考慮的是所謂的“云計算”，主流的方式有：
- IaaS (Infrastructure-as-a-Service) 基礎(chǔ)設(shè)施即服務(wù)。 模式是將虛擬機或者其他資源作為服務(wù)提供給用戶。代表有Amazon的EC2、DigitalOcean、Linode等。國內(nèi)提及的云主機，比如阿里云的ECS、騰訊云主機等，主要也是這種模式。
- PaaS (Platform-as-a-Service) 平臺即服務(wù)。 模式是將一個開發(fā)平臺作為服務(wù)提供給用戶。代表有Google App Engine、Heroku、以及國內(nèi)的新浪SAE、百度BAE等。最近
- SaaS (Software-as-a-Service) 軟件即服務(wù)。 將應(yīng)用作為服務(wù)提供給客戶。代表有 Salesforce Sales Cloud、Google Apps、Zoho等。至于各種在線建站系統(tǒng)算不算呢?我覺得也算。
在這里其實對于開發(fā)者或者是大多數(shù)站長來講，我們關(guān)注的其實只是IaaS和PaaS，SaaS主要面向終端用戶。當(dāng)我們擁有自己的應(yīng)用代碼和獨立的網(wǎng)站時，能作為我們提供程序運行載體的服務(wù)主要也在IaaS和PaaS。所以我們暫且不討論SaaS。
那么我們說說IaaS和PaaS對于普通開發(fā)者和站長來講有什么切身的利益問題。
一、自由度
IaaS自由度更大。因為選擇IaaS服務(wù)你相當(dāng)于獲得一個全新的電腦系統(tǒng)，在系統(tǒng)能力范圍內(nèi)，你在這個系統(tǒng)上想怎么玩就怎么玩，當(dāng)你的應(yīng)用或網(wǎng)站需要經(jīng)過特別的配置優(yōu)化或者有自己獨特的運行環(huán)境，那么IaaS或許是更好的選擇。比如Google的App Engine，作為一種PaaS服務(wù)它很長時間里只支持Java和Python，而且還需要通過配置文件去和它自己的運行環(huán)境去適配，雖然變相便于選擇開發(fā)方向和對開發(fā)本身作出規(guī)范，但同時也是一種掣肘，你觸碰不到服務(wù)器的“底層”沒法隨意對它的運作方式作出改動，你只能把焦點集中在代碼本身。
二、運維壓力
PaaS的運維壓力小很多。某種程度上甚至可以說運維壓力約等于0。
這就是IaaS高自由度下的代價。因為在IaaS下，郵件服務(wù)、數(shù)據(jù)庫服務(wù)、文件傳輸服務(wù)等等都可能需要自己搭建，雖然也有一些第三方的服務(wù)可以去配置，但是也免不了需要安裝好基本的服務(wù)和語言環(huán)境，從這個意義上來講，“云”的優(yōu)勢里頭“便利”這一點得不到體現(xiàn)，你還是得像“遠(yuǎn)古”那樣，具備 LAMP(Linux+Apache+MySQL+PHP)之類的知識，等花了老半天配置下來累得半死，網(wǎng)站還未必能順利跑起來。但PaaS通常只需要在服務(wù)后臺點擊一下，就能做項目的增刪改操作然后將項目代碼Push到服務(wù)平臺就了事。
事后的運維更是大頭，比如數(shù)據(jù)備份和恢復(fù)，萬一哪天服務(wù)環(huán)境出問題了，平時沒有備份那只能自認(rèn)倒霉，而如果你想換一臺機器或者更改服務(wù)方案，還有可能需要重走一系列的服務(wù)配置流程。
關(guān)鍵是，由于IaaS的性質(zhì)決定，它提供給你的是“基礎(chǔ)設(shè)施”(機器、系統(tǒng))，所以你在“基礎(chǔ)設(shè)施”上搭建的供應(yīng)用或網(wǎng)站運行的“服務(wù)平臺”到底出了什么毛病是不歸它管的，這意味著為了保證你的東西能順利健康地運行，你是需要自行投入到運維工作中去的。
而PaaS提供給你的正是“服務(wù)平臺”，所以運維壓力基本上落到了服務(wù)上身上了，因為它起碼要保證自己不出事。你只要管好你自己的代碼就行了。
三、性能
我們平常用IaaS服務(wù)，可能一個虛擬機實例里會裝上各種語言的運行環(huán)境用來運行幾個網(wǎng)站，而PaaS則是以“容器”計算，一個容器其實就是一個虛擬機，相當(dāng)于一個虛擬機就運行一個網(wǎng)站。
那么問題來了：在同樣條件下(CPU、內(nèi)存、帶寬等)一個IaaS實例運行3個不同語言環(huán)境的網(wǎng)站或者應(yīng)用，和用3個PaaS容器各自運行應(yīng)用比較起來，誰的性能更強表現(xiàn)更好?
這個問題我暫時無解。尋找Docker(PaaS技術(shù))和KVM(IaaS技術(shù))性能比較，網(wǎng)上看了不少評論和資料也是眾所紛紜。雖然一般提到Docker都說“輕量、高性能、便捷性”是其優(yōu)點，但是我沒有真正的有效地測試過。
不過一位目前專注于Docker開發(fā)的前輩有提過，Docker自己給出的結(jié)論是同樣條件下IaaS的性能還是比PaaS強——那么一丁點。
對這個問題有興趣的朋友不妨看看這個slideshow：KVM and Docker LXC benchmarking with openstack
我們從自由度、運維壓力和性能的角度對 IaaS 和 PaaS 兩種云服務(wù)對web開發(fā)者的適用性進行了PK。
下面我們將從便利性及遷移成本這兩個角度繼續(xù)探討“我的Web應(yīng)用或網(wǎng)站到底應(yīng)該在哪種云服務(wù)上運行?”這個問題。
#p#
四、便利性
有一種說法，是Docker部署應(yīng)用“像點個按鈕一樣簡單。”其實對于一般人來說，真正應(yīng)驗這句話的是PaaS服務(wù)(有些PaaS服務(wù)是建立在Docker基礎(chǔ)上的)。
做得好的PaaS在這點上是可以秒殺IaaS的。譬如GAE，當(dāng)你修改完代碼，用Google提供的軟件點一下按鈕就可以完成在本地測試和在云端運行，你甚至都不需要去知道你的代碼是怎么傳上去的。
而IaaS基于上邊所說的有前后期的運維壓力，你甚至在部署應(yīng)用之前得選擇你的服務(wù)器要安裝什么操作系統(tǒng)。
事實上現(xiàn)在PaaS服務(wù)主流的上傳方式還是有一點學(xué)習(xí)曲線的，比如你可能需要了解怎么用SVN或者GIT去更新和推送你的代碼到PaaS服務(wù)上，這個過程不比傳統(tǒng)FTP上傳來得簡單，但是本身SVN和GIT作為版本控制工具的諸多優(yōu)勢，是FTP不可比擬的，熟悉基本的使用后，一切就交給一兩句命令去完成。 而對于PaaS服務(wù)商來講，如何解決開發(fā)環(huán)境和生產(chǎn)環(huán)境里項目可能產(chǎn)生的差異是一個挑戰(zhàn)。比如你一個WordPress項目雖然通過GIT做到本地和云端的代碼一致，但是數(shù)據(jù)庫如何解決一致的問題?云端運行的版本在線安裝了插件以及上傳了圖片等靜態(tài)文件上去，這種情況造成的差異問題如何解決?
五、遷移成本
對于有運維基礎(chǔ)的人來說，IaaS比較保險，雖然麻煩一點，但是畢竟要拿回文件和數(shù)據(jù)是分分鐘的事情。
PaaS……主要看服務(wù)商怎么做，程序代碼由于能做到云端和本地天然一致，自然沒問題，問題上面一條提到的靜態(tài)文件和數(shù)據(jù)怎么辦，而且即便都拿到了，能不能在另一個平臺順利運行也是個問題。比如我當(dāng)年在GAE上運行的網(wǎng)站在GAE被墻后基本上就宣告死亡了。這個問題上我建議即使選擇PaaS，也不要選擇服務(wù)太奇葩的，GAE的問題在于它的數(shù)據(jù)庫類型，幾乎在其他環(huán)境下沒法用。盡量選擇服務(wù)環(huán)境比較通用的。
總結(jié)
總的來講，IaaS是讓服務(wù)環(huán)境去適應(yīng)項目程序，你需要花精力去做運維工作配置好適合的運行環(huán)境;PaaS是讓項目程序去適應(yīng)服務(wù)環(huán)境，你需要限制程序開發(fā)的自由度按照PaaS服務(wù)的一定規(guī)范去開發(fā)你的項目。
我建議先看看備選的PaaS服務(wù)商提供的服務(wù)是否能滿足你項目正常運行的需要，小型項目和需要快速上線的項目可以用PaaS快速部署看看效果，而使用常用CMS創(chuàng)建的網(wǎng)站，由于對運行環(huán)境的定制要求不高，也特別適合用PaaS。 如果有后期優(yōu)化運行環(huán)境需要或者程序不穩(wěn)定因素大的、有可能大改程序的，那么基于自由度的因素選擇IaaS或許更適合。
