Docker 的出現(xiàn)，讓應(yīng)用 “容器化”的門檻前所未有地降低，而這一切都在改變著我們開發(fā)應(yīng)用的方式。
今日不同以往。過去，一個(gè)單一的代碼庫(kù)就意味著一款應(yīng)用功能的全部；而現(xiàn)在，應(yīng)用被分解成為不同的功能性“片段”，你可以稱它們?yōu)椤拔⒎?wù)”，這些“微服務(wù)”共同發(fā)力，從而形成一個(gè)應(yīng)用。
與此同時(shí)，程序員們發(fā)現(xiàn)自己在線上搭建運(yùn)行這些應(yīng)用越來(lái)越困難了。原因是這些應(yīng)用不斷演化，那種“以平臺(tái)作為服務(wù)（PaaS）”，一個(gè)平臺(tái)兼容一切的特點(diǎn)再也不適合當(dāng)下的應(yīng)用開發(fā)了。
那么，讓我們說(shuō)回來(lái)，到底什么是 PaaS？
Paas 給應(yīng)用開發(fā)者們提供了一種更加方便管理、直接配置網(wǎng)頁(yè)應(yīng)用的方式，之前創(chuàng)建、配置、管理服務(wù)器等多個(gè)環(huán)節(jié)中的麻煩一概繞過了。
換句話說(shuō)，程序員現(xiàn)在只要把所有的精力都放在寫應(yīng)用，快速配置產(chǎn)品，不需要等待幾個(gè)小時(shí)（甚至好幾天）的時(shí)間才能上線。在過去，這段時(shí)間里都是需要其他人在底層平臺(tái)上進(jìn)行各種復(fù)雜的調(diào)試配置的。
P，就代表著平臺(tái)，包含了你的 App 需要運(yùn)行的一切內(nèi)容，你的應(yīng)用代碼、網(wǎng)頁(yè)服務(wù)器、代理等內(nèi)容。
在傳統(tǒng)的“PaaS”概念里，所有這些東西都是位于一個(gè)面向全世界，大型且唯一的分享性質(zhì)平臺(tái)上的。在你配置你的代碼之前，你需要確保那里有你需要運(yùn)行應(yīng)用所必備的一切。
在過去，絕大多數(shù)的人概念里，所謂的“PaaS”，無(wú)非就是借助于 AWS、Google 或者 Digital Ocean，在這些底層系統(tǒng)上面加一些好看的 UI 設(shè)計(jì)，為程序員提供命令、配置、管理服務(wù)器等工作的時(shí)候，有一些新的東西出現(xiàn)了。
比如：Heroku。
Heroku 于 2007 年上線，在 2009 年的 1 月，Heroku 發(fā)布了一個(gè)平臺(tái)新版本，從頭至尾的徹底做了革新。緊接著，在 2009 年的 3 月，Ruby on Rails 2.3 發(fā)布。其實(shí) Rails 那個(gè)時(shí)候已經(jīng)獲得了很多的人氣，而當(dāng) 2.3 版本發(fā)布之后，立刻成為了網(wǎng)頁(yè)開發(fā)上的不二選擇。
在 Rails 沒有出來(lái)之前，應(yīng)用開發(fā)環(huán)境有點(diǎn)兒像未被人涉足的美國(guó)大西部的荒野，你要么在前端使用著 Java（因?yàn)槟愕暮蠖艘彩?Java），要么你在使用 PHP，但也有一句老話說(shuō)得好：“有多少的程序員，就有多少個(gè) PHP 架構(gòu)。
而那個(gè)時(shí)候，Heroku 很精準(zhǔn)將自己定位，專門為 Rails 應(yīng)用提供服務(wù)。于是，也就在它的推動(dòng)下，PaaS 的概念開始不斷升溫。過了幾年之后，Heroku 宣布它可以支持其他的各種語(yǔ)言，使得 PaaS 支持的對(duì)象不僅僅是 Rails 了。
你當(dāng)然是不需要再操心配置服務(wù)器等工作，但是你也是得付出一些代價(jià)的，比如：
靈活性：
當(dāng)你選擇了一個(gè) PaaS 服務(wù)商，那么你就意味著你將后續(xù)的應(yīng)用開發(fā)，完全地寄托在它這里。就比如說(shuō)，Heroku 使用的是 AWS。當(dāng)你的應(yīng)用不斷增長(zhǎng)，如果你真的需要拓展到其他的地區(qū)，你會(huì)發(fā)現(xiàn)最終受限于 Amazon 所能服務(wù)的范圍。
另外，因?yàn)槟悴皇侵苯訌闹鳈C(jī)服務(wù)商那里下命令，所以你會(huì)發(fā)現(xiàn)你自己嚴(yán)重受制于 PaaS 服務(wù)商所提供的服務(wù)套餐，這會(huì)大大的限制你所配置服務(wù)器的數(shù)量和規(guī)模。
控制權(quán)：
另外一個(gè)限制體現(xiàn)在對(duì)服務(wù)器的控制權(quán)限上面。目前絕大多數(shù)的 PaaS 服務(wù)商，不會(huì)給你提供服務(wù)器的 SSH 接口，即便是有，這個(gè)接口也會(huì)存在各方面的約束限制。
再者，對(duì)服務(wù)器下達(dá)命令，只能通過這些服務(wù)商所提供的表盤來(lái)進(jìn)行，這又進(jìn)一步降低了你對(duì)服務(wù)器本身的控制，比如“重啟”這些功能。
未來(lái)應(yīng)用開發(fā)轉(zhuǎn)向微服務(wù)底層系統(tǒng)，呈現(xiàn)出“容器化”的特點(diǎn)，具體來(lái)說(shuō)，就是對(duì) Docker 這款工具的大規(guī)模應(yīng)用。
應(yīng)用開發(fā)中的容器其實(shí)已經(jīng)存在了一段時(shí)間了，最早可以追溯到 1979 年的 Chroot，從那個(gè)時(shí)候開始出現(xiàn)了迭代更新，其中包括了 FreeBSD Jail、Open VZ、LXC、以及 LMCTFY 等等。
到了 2013 年年初，Docker 橫空出世。真正讓它卓爾不群的一點(diǎn)是：它不僅僅提供“容器化”功能，而且還提供了一整個(gè)生態(tài)系統(tǒng)，在其中你可以創(chuàng)建、使用、管理容器。
容器本身有點(diǎn)兒像在某個(gè)主機(jī)里面運(yùn)行的迷你服務(wù)器。它們都可以各自從主機(jī)上提取資源，并在各自的文件系統(tǒng)中走完運(yùn)行流程。它們都是輕量級(jí)的，無(wú)論是創(chuàng)建、規(guī)模化、又或者是刪除掉，都非常方便。
各個(gè)容器都能非常完美的各自去承載某一個(gè)功能，所以也正是因?yàn)檫@一點(diǎn)，“微服務(wù)”底層系統(tǒng)才會(huì)變得如此流行。將一款應(yīng)用進(jìn)行“拆解”，其實(shí)就帶來(lái)了足夠強(qiáng)大的靈活性和穩(wěn)定性。現(xiàn)在的一款應(yīng)用再也不是過去那種包含著一個(gè)巨大的代碼庫(kù)的笨重玩意兒了。
但未來(lái)也不是說(shuō)來(lái)就來(lái)的。一款應(yīng)用拆開的各種微服務(wù)，是需要一個(gè)托管方能夠拿出來(lái)一個(gè)相應(yīng)的具有靈活性的解決方案出來(lái)的，而這，恰恰是 PaaS 所無(wú)法提供的。
應(yīng)用中的每一段代碼都有著屬于自己的“容器”。而所有的“微服務(wù)”組成了一個(gè)生態(tài)系統(tǒng)，這是隨著你的應(yīng)用嵌入到任何環(huán)境中所應(yīng)時(shí)而變的。你的代碼去哪兒，你的系統(tǒng)底層也就跟著去哪兒。
想象一下，現(xiàn)在有一個(gè)本地環(huán)境可以自由地分布出去，讓開發(fā)團(tuán)隊(duì)的每個(gè)人都能介入其中，甚至是新招來(lái)的人都能快速上手！是不是很酷？！
微 PaaS 可以讓程序員快速創(chuàng)建出一個(gè)開發(fā)環(huán)境，并立刻著手對(duì)應(yīng)用的開發(fā)。
另外，因?yàn)檫@些環(huán)境本身具備了“分布式”的特點(diǎn)，所以你不用再將其跟某一個(gè)特定的托管商進(jìn)行綁定。應(yīng)用再也不需要一個(gè)“全棧式”或者“單一托管”的 PaaS 解決方案，它們所依托的底層平臺(tái)跟它們一樣靈活。
但是，這里還存在著一個(gè)巨大的風(fēng)險(xiǎn)。正如 PaaS 需要諸如 Heroku 這樣的平臺(tái)才能夠真正釋放出自己全部的潛力，微 PaaS 同樣也需要一個(gè)產(chǎn)品，能夠?qū)⒐芾?Docker 和容器的復(fù)雜性全部給抽離出去。
盡管“容器化”確實(shí)是挺酷的，但是它讓開發(fā)工作回到了 PaaS 出現(xiàn)之前的那個(gè)階段。現(xiàn)在，不用再對(duì)服務(wù)器進(jìn)行配置和管理了，但是程序員需要在服務(wù)器內(nèi)部對(duì)“容器”進(jìn)行配置和管理；你也不用單純負(fù)責(zé)對(duì)服務(wù)器的底層系統(tǒng)進(jìn)行維護(hù)了，你現(xiàn)在需要做的是在服務(wù)器的底層系統(tǒng)內(nèi)部，對(duì)“容器”所組成的這么一個(gè)底層系統(tǒng)進(jìn)行維護(hù)！（也就是底層系統(tǒng)的底層系統(tǒng)！）
因?yàn)楝F(xiàn)在出現(xiàn)了對(duì)容器設(shè)計(jì)和管理的需求，諸如 Kubenetes（K8s）和 Docker Swarm 這樣的工具就出現(xiàn)了。這些工具確實(shí)能夠解決某個(gè)具體的問題，但是它們各自都有著十分陡峭的學(xué)習(xí)曲線，復(fù)雜程度不低，所以能真正用好它們確實(shí)還得劃上一個(gè)問號(hào)。
正如 PaaS 將底層的配置和管理給抽取出來(lái)，微 PaaS 將需要某款工具，將所有容器的配置、設(shè)計(jì)、管理的功能給抽取出來(lái)。
Nanobox 就是一個(gè)很好的例子，證明現(xiàn)在用微PaaS 正當(dāng)時(shí)。它將程序員在微PaaS上所需要的一切都考慮進(jìn)去了，配置和管理容器和服務(wù)器的復(fù)雜性，全部交由它來(lái)處理。這種靈活性的最大化，和控制權(quán)的回歸，再加上 Nanobox 所提供的便捷性，這一切使得應(yīng)用開發(fā)的未來(lái)清晰可見。
