概要

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

　　本文作為筆者過去十年的工作總結(jié)，對PaaS的實踐和思考。 筆者曾在新浪供職九年時間，參與并負責研發(fā)內(nèi)部動態(tài)平臺(私有PaaS)的建設(shè)并在后來領(lǐng)導(dǎo)了整個SAE(公有PaaS)項目的發(fā)展，因為有了動態(tài)平臺的實踐經(jīng)驗，也才有了后來SAE的誕生，兩者有因果聯(lián)系。

　　動態(tài)平臺(Dynamic Pool)

　　這個名詞是和靜態(tài)池相對的。因為新浪在很早就為新聞業(yè)務(wù)構(gòu)建了一個靜態(tài)池（目前仍在沿用）。

　　起源

　　動態(tài)平臺的立項在2004年，當時CTO李嵩波先生負責新浪技術(shù)工作，他對這個項目非常支持。童劍當時是這個項目的帶頭人。

　　當時的動態(tài)平臺解決的問題：

　　資源共用 避免一個應(yīng)用一堆機器

　　開發(fā)有規(guī)范 不能按照每個開發(fā)人員的好惡

　　統(tǒng)一的運維管理 開發(fā)人員不管理機器，只負責代碼編寫和數(shù)據(jù)庫設(shè)計

　　發(fā)展

　　動態(tài)平臺的發(fā)展初期，得益于公司領(lǐng)導(dǎo)的支持和成本管理的加強。這使得新項目申請設(shè)備預(yù)算變得困難，進而促進了動態(tài)平臺的快速發(fā)展。

　　發(fā)展過程中遇到的主要難題：

　　資源爭搶沖突問題

　　故障排查難度大

　　數(shù)據(jù)庫管理面臨挑戰(zhàn)

　　開發(fā)和運維的協(xié)作配合

　　這些難題在動態(tài)平臺不同的發(fā)展時期，表現(xiàn)程度也不盡相同。在不同時期，都有相應(yīng)的流程或技術(shù)來解決這些問題。

　　壯大

　　2009年，微博技術(shù)負責人決定使用動態(tài)平臺，這使得動態(tài)平臺的承載規(guī)模在隨后幾年都呈現(xiàn)了井噴式的高速發(fā)展。并使得動態(tài)平臺的適應(yīng)能力更強。

　　動態(tài)平臺快速發(fā)展壯大的根本原因在于公司領(lǐng)導(dǎo)支持和嚴格的成本管理，削減業(yè)務(wù)部門IT預(yù)算。這一點可供想搞私有IaaS或私有PaaS的企業(yè)參考，如果你們的預(yù)算很多，那么搞私有云，十有八九是要失敗的！很明顯，業(yè)務(wù)部門的IT預(yù)算足夠，是沒有能動性去使用私有云的。

　　如果要問全球業(yè)務(wù)規(guī)模最大的PaaS是哪一家，那一定是新浪研發(fā)的動態(tài)平臺！

　　SAE

　　2008年Google GAE發(fā)布。筆者當時正負責動態(tài)平臺的日常管理。當時的GAE我看到后非常驚艷，開發(fā)人員可以自助管理自己的應(yīng)用，寫好代碼提交后就直接運行。而當時動態(tài)平臺還是工單時代，開發(fā)人員需要提交應(yīng)用申請，我們在后臺進行手工配置后開通。當時就有一股沖動，想要搞一個類似的產(chǎn)品。這在2009年成為現(xiàn)實。2009年11月SAE如愿上線，并很快發(fā)布了alpha1、alpha2、beta等多個版本。隨著微博的蓬勃發(fā)展，2011年微博開放平臺應(yīng)用的蓬勃發(fā)展，有力地帶動了SAE的飛速發(fā)展，當時的微博投票、粉絲匯、微博數(shù)據(jù)分析、聊天工具等大量第三方的應(yīng)用快速地在SAE上誕生，并且日訪問量都可以輕松過千萬。

　　挑戰(zhàn)

　　SAE的技術(shù)架構(gòu)，很有多動態(tài)平臺的影子。其運營維護也得益于過去多年成熟的經(jīng)驗。但外部用戶和內(nèi)部用戶的差別，對SAE的影響很大，特別是后來IaaS和云主機在國內(nèi)快速發(fā)展，SAE發(fā)展速度放緩。

　　外部業(yè)務(wù)的差異性大，內(nèi)部業(yè)務(wù)相對要整齊；

　　外部客戶的協(xié)作難度更高：外部客戶數(shù)量龐大，在服務(wù)支持上只能側(cè)重于重要的客戶；

　　敏感應(yīng)用監(jiān)管難度高；

　　DDoS攻擊每日不絕：這是所有做公有云的人都面臨的痛苦；

　　惡意應(yīng)用多：比如惡意的淘寶客。

　　用戶使用SAE的理由

　　毫無疑問，SAE是國內(nèi)最早的PaaS平臺，也是目前國內(nèi)最成熟、用戶規(guī)模最大的PaaS平臺。即使是在目前云計算用戶爭搶越來越激烈的今天，每天仍然有大量用戶注冊使用SAE平臺。之所以有用戶愿意使用SAE，核心的原因：

　　快速獲取App運行環(huán)境。雖然說用戶搭建一套Lamp或Tomcat環(huán)境并不復(fù)雜，但如果不是很熟練，看文檔去做，幾個小時還是需要的；

　　免運維。這個是最關(guān)鍵和核心的。使用SAE后，你完全不需要關(guān)心運維了，只要負責寫代碼，這對很多開發(fā)人員來說，很有吸引力；

　　便宜 SAE的實現(xiàn)方式，決定了它的密度最高，目前沒有其他模式可以相比。這也是為什么使用SAE會很便宜的原因。這對很多個人開發(fā)者而言很有吸引力。

　　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

　　上面的定義，應(yīng)該是對多家PaaS供應(yīng)商的產(chǎn)品的一個總結(jié)。包括GAE、Heroku、CloudFoundry、OpenShift、SAE等。翻譯為中文的意思就是：使用者只要提交應(yīng)用代碼，其余所有事由PaaS供應(yīng)商搞定。

　　這是多么美好的愿景！我想這也是所有開發(fā)者的夢想，只關(guān)心代碼，其他的都不用管，服務(wù)還都能運行得很好，99.99%的可用性，不用擔心半夜出故障還得爬起來，不用擔心數(shù)據(jù)庫忘記了備份導(dǎo)致數(shù)據(jù)丟失，不用擔心訪問量突然倍增，服務(wù)抗不住，不用擔心網(wǎng)絡(luò)故障來回切換服務(wù)。世界變得好有秩序。

　　上面描述的愿景，令人十分向往。如果真的有這樣的PaaS存在，如果GAE真的做到了這些，為何云計算的領(lǐng)導(dǎo)者是AWS，不是GAE？

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

　　如果讓我現(xiàn)在給一個PaaS的定義，我會這樣寫：PaaS是一套開發(fā)、運維的規(guī)范和流程，可以通過一些輔助工具將規(guī)范、流程沉淀下來。但同時業(yè)務(wù)和技術(shù)總是處于不斷變化的時代，流程和規(guī)范也需要適應(yīng)變化。沒有一套流程規(guī)范能讓你用一輩子，也沒有什么工具可以幫助你一勞永逸地解決所有問題。新浪動態(tài)平臺已經(jīng)有不到10年的歷史，一直都處于不斷的演進、變化、調(diào)整中，之所以需要不斷演進變化，因為技術(shù)在變化、業(yè)務(wù)在變化、組織在變化，不要期待不變，那是不可能也是做不到的。

　　PaaS解決什么問題

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

　　代碼部署能力；

　　代碼運行時環(huán)境，如Java、PHP、Ruby等；

　　各種應(yīng)用運行所需的服務(wù) 典型的是數(shù)據(jù)庫；

　　從上面的功能看，PaaS主要解決的問題是應(yīng)用的部署以及執(zhí)行。

　　PaaS不能解決什么

　　PaaS不能做到全自動、無故障的運維管理；

　　PaaS也不能代替你實施開發(fā)和運維流程的梳理，而這個我認為對企業(yè)才是最核心的，是一個開發(fā)和運維觀念的變化，光有工具是不行的；

　　PaaS需要的運營維護工具，仍然是需要你自己開發(fā)或者購買的。PaaS無法提供全套的管理工具；

　　PaaS提供的服務(wù)仍然是有限的。比如你需要LBS服務(wù)，或者消息推送服務(wù)，可能某個PaaS提供，但另外的就沒有。沒有全能廠商可以提供所有服務(wù)，如果他提供了，也一定是個花架子。

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

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

　　NiceScale

　　離開老東家新浪后，當時我立志做一個靈活性很強的PaaS，可以支持任意的軟件棧，能夠幫用戶管理維護好他的所有軟件棧。這個項目設(shè)定的目標比CloudFoundry要大，當然我們在PaaS運營上的經(jīng)驗足夠。但是Docker發(fā)展如火如荼后，一個通用的PaaS意義還有多大？而且要解決PaaS的運管方面的需求，其復(fù)雜度也很高。但最關(guān)鍵還是，用戶真的需要這么復(fù)雜的工具嗎？

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

　　從簡單入手，于是有了新的NiceScale。但NiceScale的目標沒有變，降低用戶使用云計算的復(fù)雜度一直是我們的追求，是我們矢志不渝的目標！

　　這個新的產(chǎn)品，前期只解決一個小問題，幫助你非常容易地管理多個服務(wù)器。通過批量在多個機器上執(zhí)行腳本，并將行為記錄下來。功能雖少，但是相信你使用過后，會體驗到它的強大與方便。

　　原來服務(wù)器管理也可以不再枯燥，變得有趣、很酷！

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

　　Keep it simple, stupid ... 

核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。

轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/

本文標題：PaaS，不是銀彈

本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/10839717012.html