容器本身有点儿像在某个主机里面运行的迷你服务器。它们都可以各自从主机上提取资源，并在各自的文件系统中走完运行流程。它们都是轻量级的，无论是创建、规模化、又或者是删除掉，都非常方便。

　　各个容器都能非常完美的各自去承载某一个功能，所以也正是因为这一点，“微服务”底层系统才会变得如此流行。将一款应用进行“拆解”，其实就带来了足够强大的灵活性和稳定性。现在的一款应用再也不是过去那种包含着一个巨大的代码库的笨重玩意儿了。

　　但未来也不是说来就来的。一款应用拆开的各种微服务，是需要一个托管方能够拿出来一个相应的具有灵活性的解决方案出来的，而这，恰恰是 PaaS 所无法提供的。

　　PaaS 的下一步演进的方向将是“微PaaS”（μPaaS)

　　应用中的每一段代码都有着属于自己的“容器”。而所有的“微服务”组成了一个生态系统，这是随着你的应用嵌入到任何环境中所应时而变的。你的代码去哪儿，你的系统底层也就跟着去哪儿。

　　想象一下，现在有一个本地环境可以自由地分布出去，让开发团队的每个人都能介入其中，甚至是新招来的人都能快速上手！是不是很酷？！

　　微 PaaS 可以让程序员快速创建出一个开发环境，并立刻着手对应用的开发。

　　另外，因为这些环境本身具备了“分布式”的特点，所以你不用再将其跟某一个特定的托管商进行绑定。应用再也不需要一个“全栈式”或者“单一托管”的 PaaS 解决方案，它们所依托的底层平台跟它们一样灵活。

　　进一步，退两步

　　但是，这里还存在着一个巨大的风险。正如 PaaS 需要诸如 Heroku 这样的平台才能够真正释放出自己全部的潜力，微 PaaS 同样也需要一个产品，能够将管理 Docker 和容器的复杂性全部给抽离出去。

　　尽管“容器化”确实是挺酷的，直播，但是它让开发工作回到了 PaaS 出现之前的那个阶段。现在，不用再对服务器进行配置和管理了，但是程序员需要在服务器内部对“容器”进行配置和管理；你也不用单纯负责对服务器的底层系统进行维护了，你现在需要做的是在服务器的底层系统内部，对“容器”所组成的这么一个底层系统进行维护！（也就是底层系统的底层系统！）

　　容器设计

　　因为现在出现了对容器设计和管理的需求，诸如 Kubenetes（K8s）和 Docker Swarm 这样的工具就出现了。这些工具确实能够解决某个具体的问题，但是它们各自都有着十分陡峭的学习曲线，复杂程度不低，所以能真正用好它们确实还得划上一个问号。

　　正如 PaaS 将底层的配置和管理给抽取出来，微 PaaS 将需要某款工具，将所有容器的配置、设计、管理的功能给抽取出来。

　　Nanobox 就是一个很好的例子，证明现在用微PaaS 正当时。它将程序员在微PaaS上所需要的一切都考虑进去了，配置和管理容器和服务器的复杂性，全部交由它来处理。这种灵活性的最大化，和控制权的回归，再加上 Nanobox 所提供的便捷性，这一切使得应用开发的未来清晰可见。