容器集群也還有很大的發(fā)展空間，集群的概念和應(yīng)用集群微服務(wù)化剛剛興起，在實(shí)際生產(chǎn)中會(huì)發(fā)現(xiàn)還有很多問(wèn)題需要解決：比如功能尚不完善、可靠性和穩(wěn)定性有待提高。
那插件為什么目前還不是 OCI 標(biāo)準(zhǔn)所關(guān)注的呢？OCI 目前關(guān)注的是 RunC，以一個(gè)更小的核心給業(yè)界；而插件是 RunC 補(bǔ)充，提供了很好擴(kuò)展方式：RunC 作為運(yùn)行環(huán)境，很多環(huán)境是不需要插件就可以運(yùn)行，比如大部分的 Java/Web 微服務(wù)應(yīng)用，反倒是傳統(tǒng)應(yīng)用容器化，需要用到插件，但這類應(yīng)用并不是容器化的最主流應(yīng)用，是典型的1：9現(xiàn)象。就是90%的容器應(yīng)用不需要插件，10%的應(yīng)用需要插件，但是插件帶來(lái)相當(dāng)大的復(fù)雜性。應(yīng)用容器化只須在需要哪種功能時(shí)就使用哪種相應(yīng)的插件即可。不過(guò)目前各個(gè)廠商對(duì)插件的定義和理解并不完全一樣，除去共識(shí)的網(wǎng)絡(luò)、存儲(chǔ)等插件，其他的尚模糊。比如 Docker 對(duì)插件有自己的理解，哪些是插件，是否放到運(yùn)行環(huán)境里面；Mesos 對(duì)插件的解讀范圍就更廣，所以將插件標(biāo)準(zhǔn)化的想法在我看來(lái)還是不太容易。
但是，對(duì)于網(wǎng)絡(luò)插件，業(yè)界認(rèn)識(shí)都比較統(tǒng)一，因?yàn)槭瞧毡樾枨?，并且?yīng)用的多是VPN隧道技術(shù)。如果對(duì)這類插件進(jìn)行統(tǒng)一標(biāo)準(zhǔn)化，可以便于相互之間的通用。
另外，為什么不建議小型創(chuàng)業(yè)公司考慮企業(yè)級(jí)的完整版 CaaS？和 Docker 的情況類似，這需要有企業(yè)技術(shù)經(jīng)驗(yàn)積累、規(guī)?；肆拓?cái)力的持續(xù)投入。舉個(gè)例子，在某次競(jìng)標(biāo)，一家銀行在招標(biāo)，當(dāng)時(shí)的要求就是廠商可以自我證明可以存活三年，說(shuō)明企業(yè)客戶對(duì)創(chuàng)業(yè)公司能否存活三年還是有疑慮的。
Docker興起，加力了 PaaS 的推廣
Docker 到來(lái)前，PaaS 主要在企業(yè)級(jí)市場(chǎng)，并不為公眾所知。PaaS 分成公有云和私有云市場(chǎng)。國(guó)內(nèi)公有 PaaS 云市場(chǎng)的很多廠商基本上成為了先烈，主要問(wèn)題在持續(xù)投資無(wú)法實(shí)現(xiàn)正向現(xiàn)金流，因?yàn)楸藭r(shí) PaaS 主要面向開(kāi)發(fā)者，向開(kāi)發(fā)者收費(fèi)有難度，而向開(kāi)發(fā)者/中小企業(yè)提供 IaaS 的市場(chǎng)則發(fā)展比較好。不同的是，國(guó)外最早 Heroku 、Salesforce 等在做公有云的 PaaS 比較成功，在比較長(zhǎng)時(shí)間的實(shí)踐中積累了很多 PaaS 的模型和經(jīng)驗(yàn)，后來(lái) Cloud Foundry 當(dāng)時(shí)也吸取了當(dāng)時(shí)兩者很多很好的實(shí)踐經(jīng)驗(yàn)。
Docker 的流行促進(jìn)了大家對(duì) PaaS 的認(rèn)知，當(dāng)然也有了 CaaS 的興起（如果進(jìn)行更嚴(yán)格的定義的話，Docker 是屬于 CaaS 的），把 PaaS 從企業(yè)級(jí)市場(chǎng)的認(rèn)知擴(kuò)展到了開(kāi)發(fā)者市場(chǎng)。很多人是先接受并理解了Docker，才開(kāi)始關(guān)注思考 PaaS.這是因?yàn)?PaaS 只是針對(duì)企業(yè)級(jí)用戶，很難形成普遍的知名度；而Docker是面向開(kāi)發(fā)者的，開(kāi)發(fā)者使用了 Docker 之后向團(tuán)隊(duì)推薦，團(tuán)隊(duì)再向上層同步信息，是一種自下而上的傳播。
私有云市場(chǎng)的 PaaS 最早是互聯(lián)網(wǎng)公司在無(wú)意識(shí)的做，后來(lái)Pivotal進(jìn)入市場(chǎng)，逐步定義了 PaaS 完整的架構(gòu)，我們最早的商業(yè)客戶是在 2013 年底，那時(shí)Pivotal需要向客戶從 0 開(kāi)始講解私有云的概念，而現(xiàn)在對(duì)于技術(shù) fans 的客戶，只需要說(shuō) PaaS 是在 Docker 的基礎(chǔ)上做了那些技術(shù)工作即可。
放眼未來(lái)，PaaS 和 CaaS 可以各自輝煌
PaaS 和 CaaS 兩者有重合的部分，但是也有不同的側(cè)重：CaaS 是提供一個(gè)容器，里面是跑應(yīng)用跑數(shù)據(jù)庫(kù)等都可以；而 PaaS 更關(guān)注的是應(yīng)用，要對(duì)應(yīng)用進(jìn)行監(jiān)控，要有應(yīng)用框架、通用的應(yīng)用功能如 Session 集中管理、日志服務(wù)、路由服務(wù)等。
PaaS 通過(guò)構(gòu)建包來(lái)一鍵部署應(yīng)用，這樣的做法極大的簡(jiǎn)化了應(yīng)用的安裝部署，也是遵循DevOps 的理念。相反，Docker 讓開(kāi)發(fā)者去寫(xiě)復(fù)雜的腳本部署應(yīng)用，比如目前DockerFile 和 Docker Compose，這對(duì)于開(kāi)發(fā)者而言很痛苦乃至不可行的環(huán)節(jié)，這要求的不是業(yè)務(wù)編碼技能，而是對(duì)應(yīng)用服務(wù)器、對(duì)操作系統(tǒng)腳本的編程技能。CaaS 不限于應(yīng)用平臺(tái)，它也不專注于解決應(yīng)用平臺(tái)問(wèn)題，所以它也不善于解決應(yīng)用平臺(tái)的問(wèn)題。
和 CaaS 不同， PaaS（Heroku、Cloud Foundry等）把應(yīng)用相關(guān)的復(fù)雜度屏蔽，只需一鍵部署應(yīng)用即可運(yùn)行起來(lái)，無(wú)需關(guān)注應(yīng)用環(huán)境的安裝環(huán)節(jié)，還有應(yīng)用故障自動(dòng)恢復(fù)、自動(dòng)彈性伸縮、灰度發(fā)布等使得應(yīng)用運(yùn)維可以全自動(dòng)化?；氐?Docker 而言，其實(shí)它對(duì)DevOps 仍然有一定難度：Dockerfile / Compose 的書(shū)寫(xiě)一般是運(yùn)維人員在做的事情，而Docker鏡像打好了需要交給開(kāi)發(fā)人員，并沒(méi)有辦法做的很完美，很多地方?jīng)]有辦法完全固定，比如開(kāi)發(fā)人員發(fā)現(xiàn)需要更改一個(gè)應(yīng)用服務(wù)器的端口這么簡(jiǎn)單的一件事情，這可能就涉及到一系列的腳本的改寫(xiě)，但這個(gè)事情到底是運(yùn)維人員來(lái)做還是開(kāi)發(fā)人員來(lái)做？運(yùn)維人員來(lái)做那就不是 DevOps 了，如果開(kāi)發(fā)人員來(lái)做，開(kāi)發(fā)人員又很難具備運(yùn)維人員的腳步編程技巧。而這一點(diǎn) Heroku 和 Cloud Foundry 已經(jīng)注意到了，并通過(guò)構(gòu)建包徹底分離了運(yùn)維人員和開(kāi)發(fā)人員的分工。