为什么说"微 PaaS"代表着未来应用开发的方向？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

进一步，退两步

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

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

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

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

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

标签： 程序员 解决方案 

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。