Docker 的出現(xiàn)，讓應(yīng)用 “容器化”的門檻前所未有地降低，而這一切都在改變著我們開發(fā)應(yīng)用的方式。

今日不同以往。過去，一個單一的代碼庫就意味著一款應(yīng)用功能的全部；而現(xiàn)在，應(yīng)用被分解成為不同的功能性“片段”，你可以稱它們?yōu)?ldquo;微服務(wù)”，這些“微服務(wù)”共同發(fā)力，從而形成一個應(yīng)用。

與此同時，程序員們發(fā)現(xiàn)自己在線上搭建運(yùn)行這些應(yīng)用越來越困難了。原因是這些應(yīng)用不斷演化，那種“以平臺作為服務(wù)（PaaS）”，一個平臺兼容一切的特點(diǎn)再也不適合當(dāng)下的應(yīng)用開發(fā)了。

那么，讓我們說回來，到底什么是 PaaS？

Paas 給應(yīng)用開發(fā)者們提供了一種更加方便管理、直接配置網(wǎng)頁應(yīng)用的方式，之前創(chuàng)建、配置、管理服務(wù)器等多個環(huán)節(jié)中的麻煩一概繞過了。

換句話說，程序員現(xiàn)在只要把所有的精力都放在寫應(yīng)用，快速配置產(chǎn)品，不需要等待幾個小時（甚至好幾天）的時間才能上線。在過去，這段時間里都是需要其他人在底層平臺上進(jìn)行各種復(fù)雜的調(diào)試配置的。

P，就代表著平臺，包含了你的 App 需要運(yùn)行的一切內(nèi)容，你的應(yīng)用代碼、網(wǎng)頁服務(wù)器、代理等內(nèi)容。

在傳統(tǒng)的“PaaS”概念里，所有這些東西都是位于一個面向全世界，大型且唯一的分享性質(zhì)平臺上的。

在你配置你的代碼之前，你需要確保那里有你需要運(yùn)行應(yīng)用所必備的一切。

在過去，絕大多數(shù)的人概念里，所謂的“PaaS”，無非就是借助于 AWS、Google 或者 Digital Ocean，在這些底層系統(tǒng)上面加一些好看的 UI 設(shè)計(jì)，為程序員提供命令、配置、管理服務(wù)器等工作的時候，有一些新的東西出現(xiàn)了。

比如：Heroku。

Heroku 于 2007 年上線，在 2009 年的 1 月，Heroku 發(fā)布了一個平臺新版本，從頭至尾的徹底做了革新。緊接著，在 2009 年的 3 月，Ruby on Rails 2.3 發(fā)布。其實(shí) Rails 那個時候已經(jīng)獲得了很多的人氣，而當(dāng) 2.3 版本發(fā)布之后，立刻成為了網(wǎng)頁開發(fā)上的不二選擇。

在 Rails 沒有出來之前，應(yīng)用開發(fā)環(huán)境有點(diǎn)兒像未被人涉足的美國大西部的荒野，你要么在前端使用著 Java（因?yàn)槟愕暮蠖艘彩?Java），要么你在使用 PHP，但也有一句老話說得好：“有多少的程序員，就有多少個 PHP 架構(gòu)。”

而那個時候，Heroku 很精準(zhǔn)將自己定位，專門為 Rails 應(yīng)用提供服務(wù)。于是，也就在它的推動下，PaaS 的概念開始不斷升溫。過了幾年之后，Heroku 宣布它可以支持其他的各種語言，使得 PaaS 支持的對象不僅僅是 Rails 了。

你當(dāng)然是不需要再操心配置服務(wù)器等工作，但是你也是得付出一些代價的，比如：

靈活性：

當(dāng)你選擇了一個 PaaS 服務(wù)商，那么你就意味著你將后續(xù)的應(yīng)用開發(fā)，完全地寄托在它這里。就比如說，Heroku 使用的是 AWS。當(dāng)你的應(yīng)用不斷增長，如果你真的需要拓展到其他的地區(qū)，你會發(fā)現(xiàn)最終受限于 Amazon 所能服務(wù)的范圍。

另外，因?yàn)槟悴皇侵苯訌闹鳈C(jī)服務(wù)商那里下命令，所以你會發(fā)現(xiàn)你自己嚴(yán)重受制于 PaaS 服務(wù)商所提供的服務(wù)套餐，這會大大的限制你所配置服務(wù)器的數(shù)量和規(guī)模。

控制權(quán)：

另外一個限制體現(xiàn)在對服務(wù)器的控制權(quán)限上面。目前絕大多數(shù)的 PaaS 服務(wù)商，不會給你提供服務(wù)器的 SSH 接口，即便是有，這個接口也會存在各方面的約束限制。

再者，對服務(wù)器下達(dá)命令，只能通過這些服務(wù)商所提供的表盤來進(jìn)行，這又進(jìn)一步降低了你對服務(wù)器本身的控制，比如“重啟”這些功能。

未來應(yīng)用開發(fā)轉(zhuǎn)向微服務(wù)底層系統(tǒng)，呈現(xiàn)出“容器化”的特點(diǎn)，具體來說，就是對 Docker 這款工具的大規(guī)模應(yīng)用。

應(yīng)用開發(fā)中的容器其實(shí)已經(jīng)存在了一段時間了，最早可以追溯到 1979 年的 Chroot，從那個時候開始出現(xiàn)了迭代更新，其中包括了 FreeBSD Jail、Open VZ、LXC、以及 LMCTFY 等等。

到了 2013 年年初，Docker 橫空出世。真正讓它卓爾不群的一點(diǎn)是：它不僅僅提供“容器化”功能，而且還提供了一整個生態(tài)系統(tǒng)，在其中你可以創(chuàng)建、使用、管理容器。

容器本身有點(diǎn)兒像在某個主機(jī)里面運(yùn)行的迷你服務(wù)器。它們都可以各自從主機(jī)上提取資源，并在各自的文件系統(tǒng)中走完運(yùn)行流程。它們都是輕量級的，無論是創(chuàng)建、規(guī)?；?、又或者是刪除掉，都非常方便。

各個容器都能非常完美的各自去承載某一個功能，所以也正是因?yàn)檫@一點(diǎn)，“微服務(wù)”底層系統(tǒng)才會變得如此流行。將一款應(yīng)用進(jìn)行“拆解”，其實(shí)就帶來了足夠強(qiáng)大的靈活性和穩(wěn)定性。現(xiàn)在的一款應(yīng)用再也不是過去那種包含著一個巨大的代碼庫的笨重玩意兒了。

但未來也不是說來就來的。一款應(yīng)用拆開的各種微服務(wù)，是需要一個托管方能夠拿出來一個相應(yīng)的具有靈活性的解決方案出來的，而這，恰恰是 PaaS 所無法提供的。

應(yīng)用中的每一段代碼都有著屬于自己的“容器”。而所有的“微服務(wù)”組成了一個生態(tài)系統(tǒng)，這是隨著你的應(yīng)用嵌入到任何環(huán)境中所應(yīng)時而變的。你的代碼去哪兒，你的系統(tǒng)底層也就跟著去哪兒。

想象一下，現(xiàn)在有一個本地環(huán)境可以自由地分布出去，讓開發(fā)團(tuán)隊(duì)的每個人都能介入其中，甚至是新招來的人都能快速上手！是不是很酷？！

微 PaaS 可以讓程序員快速創(chuàng)建出一個開發(fā)環(huán)境，并立刻著手對應(yīng)用的開發(fā)。

另外，因?yàn)檫@些環(huán)境本身具備了“分布式”的特點(diǎn)，所以你不用再將其跟某一個特定的托管商進(jìn)行綁定。應(yīng)用再也不需要一個“全棧式”或者“單一托管”的 PaaS 解決方案，它們所依托的底層平臺跟它們一樣靈活。

但是，這里還存在著一個巨大的風(fēng)險。正如 PaaS 需要諸如 Heroku 這樣的平臺才能夠真正釋放出自己全部的潛力，微 PaaS 同樣也需要一個產(chǎn)品，能夠?qū)⒐芾?Docker 和容器的復(fù)雜性全部給抽離出去。

盡管“容器化”確實(shí)是挺酷的，但是它讓開發(fā)工作回到了 PaaS 出現(xiàn)之前的那個階段?，F(xiàn)在，不用再對服務(wù)器進(jìn)行配置和管理了，但是程序員需要在服務(wù)器內(nèi)部對“容器”進(jìn)行配置和管理；你也不用單純負(fù)責(zé)對服務(wù)器的底層系統(tǒng)進(jìn)行維護(hù)了，你現(xiàn)在需要做的是在服務(wù)器的底層系統(tǒng)內(nèi)部，對“容器”所組成的這么一個底層系統(tǒng)進(jìn)行維護(hù)?。ㄒ簿褪堑讓酉到y(tǒng)的底層系統(tǒng)?。?/p>

容器設(shè)計(jì)因?yàn)楝F(xiàn)在出現(xiàn)了對容器設(shè)計(jì)和管理的需求，諸如 Kubenetes(K8s)和 Docker Swarm 這樣的工具就出現(xiàn)了。這些工具確實(shí)能夠解決某個具體的問題，但是它們各自都有著十分陡峭的學(xué)習(xí)曲線，復(fù)雜程度不低，所以能真正用好它們確實(shí)還得劃上一個問號。

正如 PaaS 將底層的配置和管理給抽取出來，微 PaaS 將需要某款工具，將所有容器的配置、設(shè)計(jì)、管理的功能給抽取出來。

Nanobox 就是一個很好的例子，證明現(xiàn)在用微PaaS 正當(dāng)時。它將程序員在微PaaS上所需要的一切都考慮進(jìn)去了，配置和管理容器和服務(wù)器的復(fù)雜性，全部交由它來處理。這種靈活性的最大化，和控制權(quán)的回歸，再加上 Nanobox 所提供的便捷性，這一切使得應(yīng)用開發(fā)的未來清晰可見。