IaaS

IaaS階段， 使用者租借基礎設施，但是還是需要像以前管理伺服器那樣，用指令碼或者手工方式在這些機器上部署應用。這個過程中當然難免會碰到雲端機器和本地機器環境不一致的問題。想想每一次同步不同機器環境的過程，就知道這個過程的艱辛！

PaaS

2013年，Cloud Foundry開啟了以開源PaaS為核心構建平臺層服務能力的變革, 通過在容器底層使用Namespace和Cgroups對應用進行隔離，Cloud Foundry通過這個隔離的沙箱讓多個應用能在一起互不干涉的執行。

百度百科:
Cloud Foundry支援多種框架、語言、執行時環境、雲平臺及應用服務，通過一套應用的打包和分發機制，使開發人員能夠在幾秒鐘內進行應用程式的部署和擴充套件，無需擔心任何基礎架構的問題。
 

雖然Cloud Foundry提供了一個更好的使用者體驗，但是還是存在易用性問題：

對於一個"正確的"應用包，Cloud Foundry能實現快速部署，但為了能打包出這個"正確的"應用包, 過程卻很繁瑣，使用者可能需要為不同語言和框架，甚至每個版本打一個包，而打好的包在本地能正常執行，但是在雲端卻不一定能正常執行。

CaaS

這個時候，Docker專案開源了，雖然Docker底層和Cloud Foundry一樣，都是使用Namespace和Cgroups技術，但是另外的一小部分功能，卻成為了Docker專案後面成功的關鍵：

通過打包整個根檔案系統，把應用的所有依賴(包括作業系統檔案)都打包到一起，生成Docker映象，Docker通過Docker映象解決了Cloud Foundry打包繁瑣和不一致性的問題，提供了一種"
 
build once, run anyway"的優雅解決辦法！

容器編排(Container Orchestration)

雖然Docker專案發展迅猛，但是對於使用者而言，最終要部署的，還是他們的網站、服務甚至雲端計算等。一個Docker中執行的是一個程序，對於使用者的大規模叢集而言，只有提供平臺層能力的工具才會真正吸引他們。這種情況下，支援大叢集容器管理的Docker Swarm和Kubernetes來了。

這裡不討論各大公司間狗血的爭鬥，只簡單討論下為什麼Docker Swarm最終落敗於Kubernetes:

Docker Swarm通過Docker映象部署應用，但是實際上一個Docker容器裡只管理一個程序。現實環境下，提供一個完整的服務通常需要多容器配合才行，比如容器A和容器B/C配合提供服務，且容器A需要容器B/C先啟動, Swarm裡面對這種情況的處理就比較麻煩。而Kubernetes卻通過Pod輕鬆的解決了這一點。