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轻松的解决了这一点。