如果我使用 Docker ，还需要 PaaS 吗？

早些年，我写过一篇文章：《如果我使用Docker，还需要OpenStack吗？》，我在那篇文章中探讨了围绕Docker带来的一个颠覆方面的困惑。我在这篇文章中想接着探讨围绕同一个概念方面的另一个类似话题：使用传统方式的PaaS与使用标准的Docker方法。

背景介绍

简单来说，PaaS是一种平台，让开发人员能够将底层基础设施的许多细节抽象出来，从而迅速开发Web应用程序，并迅速部署到生产环境中，Docker则提供了一种通用的容器，能够以一种易于移植的方式包装软件堆栈。

传统的PaaS堆栈

许多传统的PaaS实现方法使用Docker或LXC作为底层容器，支持在共享基础设施上的多租户应用程序。通常，PaaS依赖专门针对某种语言（Tomcat、Jetty/Java、modephp/PHP、Rails/Ruby、Django/Python和NodeJS/JavaScript等）的Web容器，托管用户的代码，依赖Docker或LXC容器作为含有这些Web容器的轻量级虚拟机，并在各个Web容器之间提供所需的隔离级别。这种架构很适合常常利用Web前端构建的简单Web应用程序，以及数据库即后端持久模式。据我所知，Docker实际上最初由DotCloud提供的一种PaaS而来，后来演变成目前这种形式。

作为一种简单的抽象技术，Docker的引入已将Docker变成一种易于移植的软件容器，并不与某种特定的语言或框架绑在一起。它不仅可以用作Web容器，还可以用作一种更通用的软件容器，面向各种各样的应用，比如微服务、大数据分析、数据流处理以及遗留应用程序。

一些PaaS实现方法（比如CloudFoundry）已经开始支持运行中的Docker容器作为该平台支持的软件组件之一。

话虽如此，PaaS却为我们构建和包装应用程序的方式提供了一种相当固执己见的模式。随着我们开始逐渐采用更具扩展性的模式，比如微服务，我们的包装常常受到太大的限制。

这导致今天许多用户质疑：既然用户可以直接在Docker上运行，PaaS是否有足够的附加值，以便忍受这些局限性？

使用Docker作为PaaS的替代方案

如果结合使用Docker和编排引擎就能提供一种相对简单的方法，以自动化方式包装、部署和管理应用程序；编排引擎包括Kubernetes（在GCE情况下）、OpenStack情况下的Heat，或者Cloudify（面向裸机和多个云，比如OpenStack、VMware和AWS）。不像传统的PaaS堆栈，Docker并不强制采用某种特定的固执己见的架构来部署应用程序，不过它确实很适合Web应用程序和微服务架构。

我的观点

PaaS承诺的主要优点在于加快开发和使用简单。传统的PaaS实现方法实现这一目标的手段是，借助针对底层基础设施的极端抽象，以及主张采用一种固执己见的架构，这为适合这种模式的应用程序提供了一种高度优化和一致的部署体验。两者结合最终确实有助于实现这一承诺，不过只适合一些相当有限的应用环境。

使用Docker结合编排引擎作为替代方案，提供了一种更通用的平台来实现类似的目标。不像传统的PaaS方法，这种使用Docker和编排引擎的方法确实将更多的门道和基础设施细节暴露在用户面前，这让开发和部署简单Web应用程序的用户体验变得比PaaS方法来得更复杂，但是它确实提供了另一个好处：灵活性――就像OpenStack和整个开源云一样。

看待PaaS和Docker的正确视角

在我看来，看待两者的正确视角在于分层方法：PaaS容器和Docker相辅相成，如下图所示。

从上图可以看出，PaaS变成了部署简单Web应用程序的一种用例（use case）。如果部署更复杂的应用程序，直接使用Docker来得更合理。在这种情况下，编排引擎成为了管理这两种用例的核心部分。编排引擎还在应用程序组件和底层基础设施之间提供了一层抽象。

要认识到的重要一点是，在这种情况下，我们所知道的PaaS变得更像是扮演小众角色，不过仍然是一种相当常见和重要的用例。同样值得一提的是，这两种模式并非水火不容。在PaaS容器上运行的应用程序可以与直接通过Docker容器来管理的服务进行交互，就像你使用其他云服务那样，比如数据库即服务、负载均衡器即服务，或其他任何按需资源。

另外要注意的重要方面是，Docker和编排引擎这个组合打开了一条新的通道，不仅可以管理IaaS环境上的动态工作负载，还可以管理直接在裸机上的工作负载。我开始看到更多的用例出现：这种选择方案变得更受欢迎，尤其是用来管理开发和测试环境，而使用完备的云基础设施在这类环境下可能完全是大材小用。

结束语

几年前我们开始踏上向云迁移之旅时，底层云基础设施非常复杂。因而，想简化应用程序部署体验，唯一可行的办法就是在抽象层面采取极端措施，另外强行采用一种固执己见的架构，确保应用程序符合典型的云架构。随着底层基础设施和工具的不断发展，不再需要为所有用例采取那些极端措施了。我们现在看到，PaaS架构中之前嵌入在“PaaS”设备里面的部分发生了转变，比如已变得更通用的容器和编排引擎。

这一切的好消息是，作为用户，我们终于开始获得PaaS的简单性，而之前这个优点仅限于部署全新的Web应用程序，PaaS可与范围广泛得多的应用程序和架构类型结合使用。

所以，回到文章一开始的那个问题：如果我使用Docker，还需要PaaS吗？回答是肯定的。两者结合使用有其必要性，但是我们所知道的PaaS其角色已经大大弱化。

欢迎加入，群主微信：aclood