什么是PaaS？我们用一个通俗的例子来解释。如果我们现在是一个烧饼店老板，采用IaaS模式意味着我们需要用别人厨房、锅炉、煤气，自己和面做馅料，做烧饼。如果是PaaS，我们烧饼的面粉、馅料和调料都是别人提供好了，我们只需要把饼烤熟。
云厂商该如何构建一套好用的PaaS服务呢？借力开源项目，成为各厂商的共识。
Cloud Foundry开启PaaS开源时代PaaS的核心是平台。最早出现在开发者视野中的PaaS开源项目中，vmware创立的Cloud Foundry是知名度最高的。与IaaS提供云上虚拟机的服务方式不同，基于Cloud Foundry的云计算能够提供应用托管的功能。开发者只需要通过一条简单的命令比如：cf push "我的应用"，就可以将项目打成一个压缩包，上传到Cloud Foundry服务器。而Cloud foundry会开启自己的调度器，在一群云主机中找到满足用户需求的主机（系统版本、性能、个数），然后通过容器化技术，在主机上创建一个容器，在容器中下载压缩包，解压并运行，最终成为一个对外提供服务的应用。
此外，Cloud Foundry平台对这些应用项目提供分发，灾备，监控，重启等等服务（这也是我们提供给用户的核心服务）。这种托管服务解放了开发者的生产力，让他们不用再关心应用的运维状况，而是专心开发自己的应用。而这就是PaaS的“初心”，平台即服务。
（Cloud Foundry提供的服务）
这里就会有同学问了，容器是什么？容器是用来解决多个应用资源冲突与隔离性问题的技术。Linux上的namespace机制和cgroups命令都能用做资源隔离和限制，这些都是容器技术。
容器技术并不是Docker创建的，在Docker兴起之前，就已经被其他公司商用了，但是为什么现在一谈起容器，所有人第一时间想到的就是Docker呢？这就要提到Cloud Foundry的死亡。
从Cloud Foundry到DockerCloud Foundry似乎已经和我们现在使用的云功能区别不大，但2021年的现实情况却是Cloud Foundry已经死了。
我们看过互联网上很多文章，再结合我们活字格公有云开发的经验，我们认为这个项目的致命缺陷集中它的打包机制上。
Cloud Foundry最核心的组件就是应用的打包和分发机制，也是开发者打交道最多的功能。Cloud Foundry为每一种主流的语言都定义了一套打包的方式，这些方式之间毫无章法。但就是这个打包功能，成了Cloud Foundry的软肋，一直为用户所诟病。开发者不得不为每一种语言，每一种框架，甚至是每个版本应用维护一个打好的包，还有可能出现本机运行成功，打了个包上传上去之后就无法运行的情况。情况最严重的时候，开发者在调试云平台系统上花的时间都已经比开发一个新软件的时间要长了。
本来是为赋能开发者的而生的技术，Cloud Foundry却对开发者如此不友好。当开发者的抱怨积累到一定程度，想要在PaaS浪潮中央站稳脚跟的Cloud Foundry被后起之秀Docker“红牌罚出局”也就顺理成章了。
最初，Docker是一个当时还叫dotCloud的公司（2010年由所罗门海克斯创建，Y Combinator孵化）开发的容器项目。在Cloud Foundry困于打包问题时，Docker正在悄悄积蓄力量，在开源后的短短几个月内就迅速崛起，成为一个不容忽视的PaaS技术方案，吸引了云服务开发者的眼球。
滑稽的是，在Docker刚开源的时候，Cloud Foundry的首席产品经理 James Bayer就在社区做了一次详细的对比，告诉用户Docker和Cloud Foundry一样，都是使用了Namespace和Cgroups技术的沙箱而已，没什么值得关注的。
事实上，Docker也确实就和他所说的一样，采用了这个“传统”的技术方案，但是Docker与Cloud Foundry相比，做了一点小小的创新，体现了所罗门海克斯的远见。从2010他就开始考虑应用打包的一致性与复用性问题，并提出了创新的解决方案，最终对Cloud Foundry造成了毁灭性的打击。这个解决方案就是Docker镜像。
（Docker，图片来自官网）
刚开源的Docker迅速爆火，憨态可掬的小鲸鱼，对用户友好的文档，三分钟部署一个Nginx集群的宣传语，以及Docker Image这个 “微不足道的创新”，让Docker席卷整个PaaS领域。
Docker的制胜法宝：镜像Docker成功的关键，在于Docker镜像几乎完美地解决了Cloud Foundry在打包方面的软肋。