网上已经有很多的对于容器技术和Docker相关技术如何实现的细致的介绍文档，特别是这里、这里和这里。这些文档已经足够说明，Docker是一个“很棒的解决方案”，也就是说，目前可能还没有其它方案能够和它相媲美。
容器技术增强了对资源控制的力度，这一点确实有很高的实用价值，但是对于那些需要上千台服务器一起来运行的服务而言，单纯的容器技术并没有从本质上提高任何工作负载的运行效率。如今的Docker仅仅是为了在单一的机器操作而设计，于是我们又可以提出一连串的问题：这些在集群上所运行的容器和容器中运行的工作负载应该被如何分配和协调，它们怎样才能按照资源的消耗量来进行管理？它们如何在多租户的网络环境下进行运行？它们的安全性能又该如何被保证？
或许从系统设计的角度来看，我们可以提出一个更本质的问题：当前我们所讨论的到底是不是正确的资源抽象方式？与我交流过的大多数开发者以及公司的赞助商，他们对在指定的机器上的指定容器并不感兴趣，他们真正想要的是自己的服务如何能被启动运行，产生价值，并且易于监管和维护，他们并不想了解全部的琐碎细节（至少他们希望这样），例如指定个机器上的指定个容器到底在做什么。