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