概要
首先這篇文章并非攻擊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 application
上面的定義，應該是對多家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 ...
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：PaaS，不是銀彈
本文網址：http://www.guhuozai8.cn/html/consultation/10839717012.html
相關文章
