PaaS，不是銀彈

編者按：本文作者王利俊，曾任新浪雲計算SAE總監，參與並負責研發內部動態平臺（私有PaaS）的建設並在後來領導了整個SAE（公有PaaS）專案的發展。 離開新浪後，成立了Nicescale，目前主要是面向開發者和企業提供簡單好用的伺服器管理平臺，可以管理物理機、虛擬機器、雲主機甚至Docker容器。 目前該產品還在內測中，官方表示在2014年初完成了A輪融資，具體數額不祥。 本文為筆者過去十年的工作總結，對PaaS的實踐和思考。 以下為原文：

概要

首先這篇文章並非攻擊PaaS，也不是否定PaaS的價值。 相反，筆者是想通過本文對PaaS有一個更加明確的界定，它是什麼，能處理哪些問題，不能解決哪些問題。 這樣可以對所有正在探索PaaS或準備上PaaS的企業，能有一個參考。

本文作為筆者過去十年的工作總結，對PaaS的實踐和思考。 筆者曾在新浪供職九年時間，參與並負責研發內部動態平臺(私有PaaS)的建設並在後來領導了整個SAE(公有PaaS)專案的發展，因為有了動態平臺的實踐經驗，也才有了後來SAE的誕生，兩者有因果聯繫。

動態平臺(Dynamic Pool)

這個名詞是和靜態池相對的。 因為新浪在很早就為新聞業務構建了一個靜態池（目前仍在沿用）。

起源動態平臺的立項在2004年，當時CTO李嵩波先生負責新浪技術工作，他對這個專案非常支援。 童劍當時是這個專案的帶頭人。

當時的動態平臺解決的問題：

資源共用 避免一個應用一堆機器開發有規範 不能按照每個開發人員的好惡統一的運維管理 開發人員不管理機器，只負責代碼編寫和資料庫設計發展

動態平臺的發展初期，得益于公司領導的支援和成本管理的加強。 這使得新專案申請設備預算變得困難，進而促進了動態平臺的快速發展。

發展過程中遇到的主要難題：

資源爭搶衝突問題故障排查難度大資料庫管理面臨挑戰開發和運維的協作配合

這些難題在動態平臺不同的發展時期，表現程度也不盡相同。 在不同時期，都有相應的流程或技術來解決這些問題。

壯大

2009年，微博技術負責人決定使用動態平臺，這使得動態平臺的承載規模在隨後幾年都呈現了井噴式的高速發展。 並使得動態平臺的適應能力更強。

動態平臺快速發展壯大的根本原因在於公司領導支援和嚴格的成本管理，削減營業單位IT預算。 這一點可供想搞私有IaaS或私有PaaS的企業參考，如果你們的預算很多，那麼搞私有雲，十有八九是要失敗的！ 很明顯，營業單位的IT預算足夠，是沒有能動性去使用私有雲的。

如果要問全球業務規模最大的PaaS是哪一家，那一定是新浪研發的動態平臺！

SAE

2008年Google GAE發佈。 筆者當時正負責動態平臺的日常管理。 當時的GAE我看到後非常驚豔，開發人員可以自助管理自己的應用，寫好代碼提交後就直接運行。 而當時動態平臺還是工單時代，開發人員需要提交應用申請，我們在後臺進行手工配置後開通。 當時就有一股衝動，想要搞一個類似的產品。 這在2009年成為現實。 2009年11月SAE如願上線，並很快發佈了Alpha1、Alpha2、Beta等多個版本。 隨著微博的蓬勃發展，2011年微博開放平臺應用的蓬勃發展，有力地帶動了SAE的飛速發展，當時的微博投票、粉絲匯、微博資料分析、聊天工具等大量協力廠商的應用快速地在SAE上誕生，並且日訪問量都可以輕鬆過千萬。

挑戰

SAE的技術架構，很有多動態平臺的影子。 其運營維護也得益于過去多年成熟的經驗。 但外部使用者和內部使用者的差別，對SAE的影響很大，特別是後來IaaS和雲主機在國內快速發展，SAE發展速度放緩。

外部業務的差異性大，內部業務相對要整齊；外部客戶的協作難度更高：外部客戶數量龐大，在服務支援上只能側重于重要的客戶；敏感應用監管難度高；DDoS攻擊每日不絕：這是所有做公有雲的人都面臨的痛苦 ；惡意應用多：比如惡意的淘寶客。

使用者使用SAE的理由

毫無疑問，SAE是國內最早的PaaS平臺，也是目前國內最成熟、使用者規模最大的PaaS平臺。 即使是在目前雲計算使用者爭搶越來越激烈的今天，每天仍然有大量使用者註冊使用SAE平臺。 之所以有使用者願意使用SAE，核心的原因：

快速獲取App運行環境。 雖然說使用者搭建一套Lamp或Tomcat環境並不複雜，但如果不是很熟練，看文檔去做，幾個小時還是需要的；免運維。 這個是最關鍵和核心的。 使用SAE後，你完全不需要關心運維了，只要負責寫代碼，這對很多開發人員來說，很有吸引力；便宜 SAE的實現方式，決定了它的密度最高，目前沒有其他模式可以相比。 這也是為什麼使用SAE會很便宜的原因。 這對很多個人開發者而言很有吸引力。 PaaS解密

定義

維琪百科的解釋： In this model, the consumer creates the software using tools and/or libraries from the provider. The consumer also controls software deployment and configuration settings. The provider provides the networks, servers, storage, and other services that are required to host the consumer's applicat ion

上面的定義，應該是對多家PaaS供應商的產品的一個總結。 包括GAE、Heroku、CloudFoundry、OpenShift、SAE等。 翻譯為中文的意思就是：消費者只要提交應用代碼，其餘所有事由PaaS供應商搞定。

這是多麼美好的願景！ 我想這也是所有開發者的夢想，只關心代碼，其他的都不用管，服務還都能運行得很好，99.99%的可用性，不用擔心半夜出故障還得爬起來，不用擔心資料庫忘記了備份導致資料丟失，不用擔心訪問量突然倍增，服務抗不住， 不用擔心網路故障來回切換服務。 世界變得好有秩序。

上面描述的願景，令人十分嚮往。 如果真的有這樣的PaaS存在，如果GAE真的做到了這些，為何雲計算的領導者是AWS，不是GAE？

我不禁懷疑，這樣萬能的包治百病的PaaS真的存在嗎？ 不論是作為先行者的GAE、Heroku、SAE，還是後來的CloudFoundry、OpenShift，還是現在的基於Docker的Flynn、Deis。

如果讓我現在給一個PaaS的定義，我會這樣寫：PaaS是一套開發、運維的規範和流程，可以通過一些輔助工具將規範、流程沉澱下來。 但同時業務和技術總是處於不斷變化的時代，流程和規範也需要適應變化。 沒有一套流程規範能讓你用一輩子，也沒有什麼工具可以説明你一勞永逸地解決所有問題。 新浪動態平臺已經有不到10年的歷史，一直都處於不斷的演進、變化、調整中，之所以需要不斷演進變化，因為技術在變化、業務在變化、組織在變化，不要期待不變，那是不可能也是做不到的。

PaaS解決什麼問題

要談PaaS能夠解決哪些問題，取決於PaaS提供哪些能力，一般而言，目前的PaaS提供：

代碼部署能力；代碼運行時環境，如JAVA、PHP、Ruby等；各種應用運行所需的服務 典型的是資料庫；

從上面的功能看，PaaS主要解決的問題是應用的部署以及執行。

PaaS不能解決什麼

PaaS不能做到全自動、無故障的運維管理；PaaS也不能代替你實施開發和運維流程的梳理，而這個我認為對企業才是最核心的，是一個開發和運維觀念的變化，光有工具是不行的；PaaS需要的運營維護工具， 仍然是需要你自己開發或者購買的。 PaaS無法提供全套的管理工具；PaaS提供的服務仍然是有限的。 比如你需要LBS服務，或者消息推送服務，可能某個PaaS提供，但另外的就沒有。 沒有全能廠商可以提供所有服務，如果他提供了，也一定是個花架子。

看到上面幾點，大家是不是覺得PaaS沒什麼用？ 其實不是，PaaS只是個工具，你需要首先變革你的理念，或者你不使用CloudFoundry這麼複雜的系統，但如果你已經將你的開發和運維流程規範做得很到位，那麼確實是不需要PaaS的，或者你在實施你的流程時， 就已經自覺或不自覺地使用了某些工具，你可以非常快速地部署軟體、實施監控、有條理地進行備份，那麼你確實無需再去引入一個PaaS平臺了。

PaaS最終應該是解決方案，適應客戶需求的解決方案，而且是需要隨著業務需求的變化可以不斷演變。 而不是客戶削足適履去適應PaaS這個工具。 那樣的話，PaaS之路必定是多災多難。

NiceScale

離開老東家新浪後，當時我立志做一個靈活性很強的PaaS，可以支援任意的軟體棧，能夠幫使用者管理維護好他的所有軟體棧。 這個專案設定的目標比CloudFoundry要大，當然我們在PaaS運營上的經驗足夠。 但是Docker發展如火如荼後，一個通用的PaaS意義還有多大？ 而且要解決PaaS的運管方面的需求，其複雜度也很高。 但最關鍵還是，使用者真的需要這麼複雜的工具嗎？

我重讀Unix經典著作，思考前輩們是如何處理這樣複雜的工程的。 我們承認，服務運行的管理確實非常複雜，但是如果使用了複雜的工具去管理，那麼也只能帶來更高的複雜度。 解決複雜的問題，只有簡單，任何複雜的事情，都是可以分解為簡單。

從簡單入手，於是有了新的NiceScale。 但NiceScale的目標沒有變，降低使用者使用雲計算的複雜度一直是我們的追求，是我們矢志不渝的目標！

這個新的產品，前期只解決一個小問題，説明你非常容易地管理多個伺服器。 通過批量在多個機器上執行腳本，並將行為記錄下來。 功能雖少，但是相信你使用過後，會體驗到它的強大與方便。

原來伺服器管理也可以不再枯燥，變得有趣、很酷！

初心未變，但我們選擇了另外一條路，簡單的路。

Keep it simple, stupid ...

本文作者：王利俊（@IT人），曾負責新浪研發私有PaaS（動態平臺）和公有PaaS（SAE）。 混合雲管理平臺NiceScale.com創始人。

掃描二維碼，即可獲得NiceScale邀請碼

原文連結：PaaS，不是銀彈 - 寫在NiceScale產品變化之後（責編：周小璐）