Docker 的出现，让应用“容器化”的门槛前所未有地降低，而这一切都在改变着我们开发应用的方式。

　　今日不同以往。过去，一个单一的代码库就意味着一款应用功能的全部；而现在，应用被分解成为不同的功能性“片段”，你可以称它们为“微服务”，这些“微服务”共同发力，从而形成一个应用。

　　与此同时，程序员们发现自己在线上搭建运行这些应用越来越困难了。原因是这些应用不断演化，那种“以平台作为服务（PaaS）”，一个平台兼容一切的特点再也不适合当下的应用开发了。

　　那么，让我们说回来，到底什么是 PaaS？

　　Paas 给应用开发者们提供了一种更加方便管理、直接配置网页应用的方式，之前创建、配置、管理服务器等多个环节中的麻烦一概绕过了。

　　换句话说，程序员现在只要把所有的精力都放在写应用，快速配置产品，atv直播，不需要等待几个小时（甚至好几天）的时间才能上线。在过去，这段时间里都是需要其他人在底层平台上进行各种复杂的调试配置的。

　　P，就是代表着平台

　　P，就代表着平台，包含了你的 App 需要运行的一切内容，你的应用代码、网页服务器、代理等内容。

　　在传统的“PaaS”概念里，所有这些东西都是位于一个面向全世界，大型且唯一的分享性质平台上的。在你配置你的代码之前，你需要确保那里有你需要运行应用所必备的一切。

　　在过去，绝大多数的人概念里，所谓的“PaaS”，无非就是借助于 AWS、Google 或者 Digital Ocean，在这些底层系统上面加一些好看的 UI 设计，为程序员提供命令、配置、管理服务器等工作的时候，有一些新的东西出现了。

　　比如：Heroku。

　　Heroku 于 2007 年上线，在 2009 年的 1 月，Heroku 发布了一个平台新版本，从头至尾的彻底做了革新。紧接着，在 2009 年的 3 月，Ruby on Rails 2.3 发布。其实 Rails 那个时候已经获得了很多的人气，而当 2.3 版本发布之后，立刻成为了网页开发上的不二选择。

　　在 Rails 没有出来之前，应用开发环境有点儿像未被人涉足的美国大西部的荒野，你要么在前端使用着 Java（因为你的后端也是 Java），要么你在使用 PHP，但也有一句老话说得好：“有多少的程序员，就有多少个 PHP 架构。”

　　而那个时候，Heroku 很精准将自己定位，专门为 Rails 应用提供服务。于是，也就在它的推动下，PaaS 的概念开始不断升温。过了几年之后，Heroku 宣布它可以支持其他的各种语言，使得 PaaS 支持的对象不仅仅是 Rails 了。

　　选择 PaaS 所需要付出的代价

　　你当然是不需要再操心配置服务器等工作，但是你也是得付出一些代价的，比如：

　　灵活性：

　　当你选择了一个 PaaS 服务商，那么你就意味着你将后续的应用开发，完全地寄托在它这里。就比如说，Heroku 使用的是 AWS。当你的应用不断增长，如果你真的需要拓展到其他的地区，你会发现最终受限于 Amazon 所能服务的范围。

　　另外，因为你不是直接从主机服务商那里下命令，所以你会发现你自己严重受制于 PaaS 服务商所提供的服务套餐，这会大大的限制你所配置服务器的数量和规模。

　　控制权：

　　另外一个限制体现在对服务器的控制权限上面。目前绝大多数的 PaaS 服务商，不会给你提供服务器的 SSH 接口，即便是有，这个接口也会存在各方面的约束限制。

　　再者，对服务器下达命令，只能通过这些服务商所提供的表盘来进行，这又进一步降低了你对服务器本身的控制，比如“重启”这些功能。

　　应用未来的开发方向

　　未来应用开发转向微服务底层系统，呈现出“容器化”的特点，具体来说，就是对 Docker 这款工具的大规模应用。

　　应用开发中的容器其实已经存在了一段时间了，最早可以追溯到 1979 年的 Chroot，从那个时候开始出现了迭代更新，其中包括了 FreeBSD Jail、Open VZ、LXC、以及 LMCTFY 等等。

　　到了 2013 年年初，Docker 横空出世。真正让它卓尔不群的一点是：它不仅仅提供“容器化”功能，而且还提供了一整个生态系统，在其中你可以创建、使用、管理容器。