容器集群也还有很大的发展空间，集群的概念和应用集群微服务化刚刚兴起，在实际生产中会发现还有很多问题需要解决：比如功能尚不完善、可靠性和稳定性有待提高。
那插件为什么目前还不是 OCI 标准所关注的呢？OCI 目前关注的是 RunC，以一个更小的核心给业界；而插件是 RunC 补充，提供了很好扩展方式：RunC 作为运行环境，很多环境是不需要插件就可以运行，比如大部分的 Java/Web 微服务应用，反倒是传统应用容器化，需要用到插件，但这类应用并不是容器化的最主流应用，是典型的1：9现象。就是90%的容器应用不需要插件，10%的应用需要插件，但是插件带来相当大的复杂性。应用容器化只须在需要哪种功能时就使用哪种相应的插件即可。不过目前各个厂商对插件的定义和理解并不完全一样，除去共识的网络、存储等插件，其他的尚模糊。比如 Docker 对插件有自己的理解，哪些是插件，是否放到运行环境里面；Mesos 对插件的解读范围就更广，所以将插件标准化的想法在我看来还是不太容易。
但是，对于网络插件，业界认识都比较统一，因为是普遍需求，并且应用的多是VPN隧道技术。如果对这类插件进行统一标准化，可以便于相互之间的通用。
另外，为什么不建议小型创业公司考虑企业级的完整版 CaaS？和 Docker 的情况类似，这需要有企业技术经验积累、规模化人力和财力的持续投入。举个例子，在某次竞标，一家银行在招标，当时的要求就是厂商可以自我证明可以存活三年，说明企业客户对创业公司能否存活三年还是有疑虑的。
Docker兴起，加力了 PaaS 的推广
Docker 到来前，PaaS 主要在企业级市场，并不为公众所知。PaaS 分成公有云和私有云市场。国内公有 PaaS 云市场的很多厂商基本上成为了先烈，主要问题在持续投资无法实现正向现金流，因为彼时 PaaS 主要面向开发者，向开发者收费有难度，而向开发者/中小企业提供 IaaS 的市场则发展比较好。不同的是，国外最早 Heroku 、Salesforce 等在做公有云的 PaaS 比较成功，在比较长时间的实践中积累了很多 PaaS 的模型和经验，后来 Cloud Foundry 当时也吸取了当时两者很多很好的实践经验。
Docker 的流行促进了大家对 PaaS 的认知，当然也有了 CaaS 的兴起（如果进行更严格的定义的话，Docker 是属于 CaaS 的），把 PaaS 从企业级市场的认知扩展到了开发者市场。很多人是先接受并理解了Docker，才开始关注思考 PaaS.这是因为 PaaS 只是针对企业级用户，很难形成普遍的知名度；而Docker是面向开发者的，开发者使用了 Docker 之后向团队推荐，团队再向上层同步信息，是一种自下而上的传播。
私有云市场的 PaaS 最早是互联网公司在无意识的做，后来Pivotal进入市场，逐步定义了 PaaS 完整的架构，我们最早的商业客户是在 2013 年底，那时Pivotal需要向客户从 0 开始讲解私有云的概念，而现在对于技术 fans 的客户，只需要说 PaaS 是在 Docker 的基础上做了那些技术工作即可。
放眼未来，PaaS 和 CaaS 可以各自辉煌
PaaS 和 CaaS 两者有重合的部分，但是也有不同的侧重：CaaS 是提供一个容器，里面是跑应用跑数据库等都可以；而 PaaS 更关注的是应用，要对应用进行监控，要有应用框架、通用的应用功能如 Session 集中管理、日志服务、路由服务等。
PaaS 通过构建包来一键部署应用，这样的做法极大的简化了应用的安装部署，也是遵循DevOps 的理念。相反，Docker 让开发者去写复杂的脚本部署应用，比如目前DockerFile 和 Docker Compose，这对于开发者而言很痛苦乃至不可行的环节，这要求的不是业务编码技能，而是对应用服务器、对操作系统脚本的编程技能。CaaS 不限于应用平台，它也不专注于解决应用平台问题，所以它也不善于解决应用平台的问题。
和 CaaS 不同， PaaS（Heroku、Cloud Foundry等）把应用相关的复杂度屏蔽，只需一键部署应用即可运行起来，无需关注应用环境的安装环节，还有应用故障自动恢复、自动弹性伸缩、灰度发布等使得应用运维可以全自动化。回到 Docker 而言，其实它对DevOps 仍然有一定难度：Dockerfile / Compose 的书写一般是运维人员在做的事情，而Docker镜像打好了需要交给开发人员，并没有办法做的很完美，很多地方没有办法完全固定，比如开发人员发现需要更改一个应用服务器的端口这么简单的一件事情，这可能就涉及到一系列的脚本的改写，但这个事情到底是运维人员来做还是开发人员来做？运维人员来做那就不是 DevOps 了，如果开发人员来做，开发人员又很难具备运维人员的脚步编程技巧。而这一点 Heroku 和 Cloud Foundry 已经注意到了，并通过构建包彻底分离了运维人员和开发人员的分工。