相信有很多人對PaaS持謹慎態度,到底是用還是不用?而在前一階段“ 用戶指責Heroku私自修改路由機制造成高支出”這場風暴過境後,PaaS似乎變的更加讓人望而卻步了。然則PaaS真像這些負面所說,高投入之後卻帶不來應有的回報?下面就看一看那些來自PaaS的正能量,本文將以一個重點做陳述,下面來一覽High Scalability上總結的 小團隊PaaS成功之旅:
SongPop
SongPop,音樂版你畫我猜 游戲;於2012年5月上線,現已擁有6000萬個用戶,位列2012年iOS游戲下載榜第5。而今SongPop已有能力處理日百萬活躍用戶的線上活 動,然而問題的關鍵卻在於SongPop的工程師團隊只有6人!其中也僅有一個人在做全職的後端工作。SongPop只花了不到6個月就實現了從0到1萬 每秒查詢的擴展,他們把大部分的功勞歸結於所使用的PaaS平台 —— Goolge App Engine。
經驗總結如下:只做輕活,讓PaaS去承擔重的部分;當你需要擴展時,你只需要購買更多的資源和做少量的調整(當然,也可能會很多);得到的回報是可以專心於App的特色開發,並且能夠以很小的團隊開始。
SongPop的架構圖解:
單一的看架構圖,顯然不能知曉SongPop以6人工作團隊去支撐每天百萬活躍用戶的關鍵。下面來看一下SongPop問題解決策略:
學到的知識
通過以上幾個關鍵點,SongPop成功的實現了以6人工程師團隊處理每日百萬的在線用戶。然而從Google App Engine這個PaaS服務獲益絕不是SongPop一個,還有Rovio等:
幾個從GAE獲益的公司:
1. Ravio—— “憤怒小鳥”的擁有者。使用App Engine僅花費2周的工作就推出了游戲的網頁版,使他們能夠利用機會快速發展它們的業務。
2. GetAround—— TechCrunch Disrupt出品的汽車租賃服務,使用App Engine建立了一個連接汽車業主的市場,用戶可以從中租借汽車。幾乎無額外工作就完成了他們產品的擴展。
3. MAG Interactive—— 休閒游戲的開發者,熱門游戲Ruzzle的創建者;通過App Engine對後端進行擴展,迅速的發展到500萬用戶,期間更“老練”的未發生任何擴展問題。
4. Nubbius—— Cloud Gate使用App Engine建立,允許律師在任何地點管理其工作流程的SaaS平台。在快速部署擴展的同時,每年成本節約更超過13萬美元。
5. RedBus,在線旅行社使用Google BigQuery調度上萬汽車的日程表。不到30秒就可以分析2TB的數據(在Hadoop上需要大約一天的時間),成本卻不到Hadoop基礎設施的20%。
總結
以上闡述的是一些從Google App Engine中獲益的用例,然而從Google App Engine中獲利的公司絕不止以上幾個;同樣可以獲益的PaaS平台也絕不是Google一家所有,比如:Netflix大愛的Amazon,受廣大微 軟用戶擁護的Azure,以及廣受Rails用戶喜歡、雖然前一階段卻遭受質疑的Heroku。
由此可見,完美的服務是不存在的(畢竟還存在宕機、安全這些難以攻克的問題),選擇匹配自己業務類型(數據類型及程序原型等)的服務才是根本。同 樣,隨著PaaS平台發展的愈加成熟,各個服務的缺點會得到進一步改善,優點則會更加的突出。而經過用戶與服務供應商之間的共同努力,從中獲益的模式以及 途徑將變的更加清晰。