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