虚拟圆桌：云计算中PaaS的未来-InfoQ



 写点什么

对平台即服务（PaaS）这一概念大家众说纷纭，在云世界里它是否依然占有一席之地呢。为此，InfoQ 特意请来了四位云领域的领袖人物，分享他们对PaaS 未来的看法。

这次访问中，云前驱Krishnan Subramanian，云开发者Dan Turkenkopf，云执行官JP Morgenthal 和云专家James Urquhart 讨论了对PaaS 的误解，以及其在未来云计算中的地位。

InfoQ**：PaaS带来哪些 Iaas 没有的实际价值（非理论上的）？为什么就不能使用虚拟机来作为多种应用组合的主机？**

Krish：当然，你完全可以使用虚拟机，管理工具等设置一个用于提供类似 PaaS 价值的环境。这一点是毫无疑问的。但是 PaaS 所做的是在无缝衔接开发工具的同时，为企业市场内的 IT 商店将复杂性从自动化中带出。在我看来，这就是它的两个主要亮点，其作用就是提高开发人员的生产力，以及使组织在请求新的 DevOps 技巧上没有负担。原因在于使开发和生产紧密合作的同时，Devs 和 Ops 角色一直以来都是分开的。

JP：从这个角度上来看，我认为 PaaS 的首要作用就是简化了应用的生命周期管理，其中包括缩小应用满足用户需求和建立服务等级。考虑到不使用 PaaS 部署的应用很可用使用多层服务器方式。这意味着需建立和配置堆栈中所有不同组件，包括数据库，网页服务器，应用服务器，和负载均衡器等。这在运营上要花费相当大的精力，维护起来费用也很高。而且很多情况下，开发所用的堆栈往往和运营所用的并不完全一致。因此在开发环境下往往无法重现在生产环境下可能产生的失败。PaaS 为应用所提供的服务允许开发人员专心构建业务问题的解决方案，而非管理运营或发布堆栈。PaaS 能管理发布，并确保应用满足产品层目标服务等级。

Dan：如果这么限定该问题的话，那就有点大打折扣了。如果你就是担心管理应用组件的话，正如你所说的，是有很多选择的。但我还是觉得 PaaS 比起大多数其它的方式更加地适合企业环境，由于它为开发和运营人员创建了通用的交互模式，而这也只是一个平台的最基本价值。

当然我也不会把所有的云架构师（老理念）都叫过来，然后讨论这些抽象概念的合理分层以及相关所有内容。相反，我们可以关注 PaaS 是如何支持服务生态系统，并从中受益的。而这也是自动化容器解决方案所不能做到的。一个合理的平台允许企业服务的无缝使用，比如：验证、授权、映射 / 简化等。执行 PaaS 的最好方法是通过“不用您联系我们，我们将联系您（don’t call us, we’ll call you）”的控制反转原则。这些都可以在 CloudFoundry 服务绑定、OpenShift 插件盒和 Apprenda&Heroku 附加组件中看到。

往更深层看，我看到了 PaaS 真正的未来：经功能直接注入到应用以提供附加特性（比如 Apprenda 能处理多租户架构）或指导应用加强管理功能（可查看 William Louth 的 PaaS 理论）。但我说这些可能有点偏题。

James：该问题暴露了关于开发（及其其他人员）在使用云时候的一个重要误解。这并非是一个仅采用某一种服务的问题，而是如何去最好地通过云结合使用这些可用服务 (和其他软件)。这就是为什么我认为开发人员所关注的顶级模型最好是通过“服务即平台”这一规则来捕获的。就像思科的 Lew Tucker 和其他人提及的.

“服务即平台”从开发者角度将 SaaS，PaaS 和 IaaS 等概念结合在一起，并更多地关注有哪些服务可以被使用起来，而非如何被使用的。服务即平台驱动了一个概念，该概念包含可组合性胜于具体内容（查看这里）和“SaaS、PaaS 和 IaaS”只是涉及不同的、却往往彼此重叠的使用体验。

PaaS 在可自动化的大型在线软件应用的核心可拓展性和可用性上是否具有价值？答案当然是肯定的。但是 AWS 和其他每天不断添加的服务可用性已开始模糊了完全规范框架和完全自我组合的“IaaS”选项间的界限。

最后，PaaS 一直都涵盖了纯 IaaS（带有一些以开发者为中心的自动化抛出）和 SaaS 的有针对性扩展以及其它由上下文指定的软件模型。在大环境上, 就 PaaS 为云计算这一整体服务性消费接口（尤其重要）所真正带来的价值来看，将其“另归一类”的需要则最大化地减弱了。

InfoQ：从 Heroku 和 Google App Engine 的早期开始，PaaS 这一概念是否就已经开始演化？如果是的话，为什么以及如何演进的？

Krish：是啊，PaaS 从早期就开始演进了。开始时 PaaS 主要关注解决托管服务规模这一问题的。大多数早期平台都是通过在运算组织构造的顶层使用不同服务来构建的。为了达到规模上的有效性，早期的 PaaS 解决方案在架构上对应用进行了限制。尽管它取得了部分开发人员的兴趣，但是企业却对这些 PaaS 供应商所提出的限制有所顾虑。随着关注企业 PaaS 的出现，我们看到演进慢慢从对缩放的关注转移到提高开发者生成力，并减少限制。同时我们也看到了部分开源平台开始使用容器模式，这对应用的可移植性非常重要。

JP：从 Heroku 和 GAE 早期开始，PaaS 以概念和工具快速演进。但是我偏向将这些归类到框架，而非 PaaS。目前，PaaS 在规模上提供更多的控制，并为新服务带来了更大的集成能力。平台上有更多简化方式来满足特定服务等级。尽管如此，随着私有和共有 PaaS 的出现，这一概念肯定已产生分支。私有 PaaS 主要关注于开发人员将应用交付到 IT 运营这一过程的体验，而公共 PaaS 更多的是关心如何允许开发人员在产品环境下操作和管理应用。

James：首先，PaaS 产品试图成为开发人员编程体验整体的一部分，它为关键服务提供的架构是固定的，而且模式是“要么接受，要么不用”。很快大家就发现这一模式根本不能应用到更广范围的网页开发市场，因此早期 PaaS 供应商很快便引进更广泛的服务、编程语言和部署方法。

现代 PaaS 更多的是关于运营自动化，而非代码抽象，这是至关重要的。服务接口的标准化更多从连通性和运营角度出发，而不是从“检测服务如何被使用”的角度。Cloud Foundry 和 Heroku 所工作的生态系统就是很好的例子，它们提供了高度可组合模型，强调了运营自动化，并将应用模式的适用性拓展到最宽范围。

最后，正如我在第一个回答里指出的，最先进的 IaaS 工具所提供的自动化类型与“纯 PaaS”产品间的界限将会越来越模糊，以致服务接口标准将开始出现。PaaS 平台产品提供的增值将围绕着接口和格式的一致性展开，这将大大打开跨多供应商的应用平台市场。这时我们就会停止讨论 PaaS vs. IaaS，而开始讨论它们作为整体所能带来的效益。

Dan：早期 PaaS 基本是为个体开发人员或初创型企业处理应用级托管。这样取代了自己从托管公式购买服务器空间，且配置 LAMP 堆栈，你可以从 PaaS 供应商租用其计算资源，然后遵循其设计和部署规则。事实上，早期 PaaS 的杀手级功能就是基于 Git 的部署。这个功能不仅很酷，也缩短了开发时间，符合了“我们为开发人员简化事务”这一价值主张。

今天，‘PaaS’这一概念已被热心的市场和运营人员‘盗用’了。尽管这点看上去漫不经心，但是我还是认为有一部分是符合事实的。我们今天能有这一谈话的原因之一就是现在任意与自动化部署及规模有关的内容都叫 PaaS。因此，我们发现单个分类里却包含了这么宽范的功能。

我们在接下来 18 个月左右将看到一些对该术语的微调，而这将从如 Azure、Google Compute 和 Verizon 等这样的供应商开始。这些公司既不是 IaaS 也不是 PaaS 的供应商，但他们作为资源供应商提供了多种多样的消费形式。就这样，在我看来我们将看到一个全新的关注点，它将关注如何允许我在上一问题答案中提到过的服务模型，甚至将生成一类新的流行语。

InfoQ：大家对 PaaS 的这些描述都非常优秀，但我还是觉得有些远不可攀。现今的大部分商业（公共的）PaaS 产品不都在可管理模式下提供网页和应用服务、部署工具和应用管理工具，而不是 Krish 的“无约束环境”或 James 的“基于编码抽象上的自动化”吗？在朝着“服务及平台”这一超越传统 PaaS 约束的理想前进的路上，你在哪方面看到了相应的变化？

Dan：其实大部分传统 PaaS 供应商已经或多或少地展开该愿景一段时间了。在上一回答中，我提到了大量供应商所用的插件模式。Apprenda 的整个理念就是围绕着对客户应用的深度集成来构建的。Azure 提供了许多类似 ESB，及多因素验证等平台服务。Buildpacks 和 cartridges 现在大多用于绑定特定运行时和插件，但他们主要服务于比较健壮的组合应用。这些例子不胜枚举。

那为什么市场会呈现出对应用托管和管理的关注呢？其实部分是因为 PaaS 还处于早期，而且应用也需最先设置于平台上的。也有一部分是因为这些功能是所有对能否定义为平台因素中比较常见的线程（不管他们是否遵循 Simon Wardley 提出的正确的抽象层）。还有一部分是因为平台供应商本身也在前进。目前没有任何人有完整的解决方案，或者我们已经知道完整的解决方案是什么样子。听听我们今天的谈话就知道了。尤其相对于普通大众，我们已经有非常类似的理念了，然而我们又都赞同略不相同的结束状态，以及我能想象为了完成该状态各自将会有不同的过程。

随着使用不断成熟，平台也不断演进，越来越多的人会将 IT 作为一个整体系统，而非一堆不同的应用程序。我们也将看到 PaaS 的其它因素会被推向前沿。尽管已经有公司这么做了（比如：Netflix），但大部分都是自产自销。这点虽然很好，但不好推广。作为商业系统应用，PaaS 应该与主流一同发展。

Krish：我同意 Dan 的看法。我们对 PaaS 的采用还处于早期阶段，随着使用的增加，它也会不断演进。PaaS 依然被看作是托管的拓展的最大原因是因为 PaaS 托管服务在早期非常成功，而这些服务已经调整为了更多地满足客户处理网页应用的需求，而不是 IT 重构平台。

但这点随着越来越多的企业开始拥抱“现代 PaaS”产品开始变化，公司意识到 PaaS 为他们重构 IT 以及将其转换从而满足新挑战提供了可能。在这一点上，我喜欢 Jonathan Murray 的可组合企业这一想法，他在现代企业应如何构建其 IT 平台术语上有正确的诠释。我们看到越来越多组织拥护该方式和开放式架构的平台，这将帮助企业构建强大且灵活的平台。

当然企业内部的变化是缓慢的，PaaS 供应商在如何将它们的服务用于构建这类现代 IT 平台上还未有好的成果。但随着传感因素不断遍布企业内部，这一趋势正在快速变化，组织意识到如果不转换其 IT 方式，将错过大数据所带来的利益。

PaaS 供应商需要给企业明确的信息。现代 IT 需要大规模自动化，但这可以通过更高的命令抽象来更有效地完成。另外，他们需要很好地为 IT 人员解释下堆栈中的更高层抽象来减少错误面。

JP：你的问题倒是引出了另外一个问题，我们是否需要分开考虑私有 PaaS 和公有的 PaaS。归根结底，它们可以共享一个通用模型。但是私有 PaaS 强调了运营和应用开发两个不同责任间更深层次的区别。公有 PaaS 则巧妙地设计用于开发云应用的团队，而这些团队也很可能负责在产品上的应用管理和运营。因此我可能不会说以上的描述遥不可及，但我同意我们可能无法在一个公有 PaaS 产品上找到所有特性。

InfoQ**：JP提到了私有和公有 PaaS 间的区别。你们觉得它们是否应该各自拥有不同的特性，或其中一个环境中的某些功能比另一个中更重要？**

JP：从一方面来讲，私有 PaaS 必须能被 IT 运营人员支持。这本身就包含对管理，监控和配置的一系列需求。而在公有 PaaS 中，供应商则会负责这些需求。另外一方面，如我在上个问题中提到的，它们之间的工具也是不同的。在我看来私有 PaaS 里的工具在应用开发和 IT 运营间建立互相协作的 DevOps 流程，而公有 PaaS 则关注为工程师或开发人员提供用于支持和简化应用部署和管理流程的工具。

Dan：其实主要的区别不在私有对公有；而是中间件 VS 运营服务。平台功能应完全与其运行的计算服务分离开来。这样才能保证不同服务交付形式下，从裸机到内部虚拟化，再到混合语，最后完全公开，应用体验一致。应用平台的选择结果不应由完全无关的决定来支配。

很显然公司会根据是否自己运营平台来做决定。这样类似机器和策略的管理就成为评价标准中的重要部分，不然这些因素可能会被忽略。但这不能消除管理平台的需要，只是改变了谁应负责。对于平台供应商，不论是内部还是外部服务供应商来实现该功能都不应是个问题。

如果初始 PaaS 供应商在没有试图提供软件及提供底层运行环境的话，市场会强制要求他们跟上发展步伐。我们持续将两个领域的责任混合在一起的话将是个不幸的遗留问题，而非特色。

Krish：我同意 Dan 的说法，这与私有还是公有无关。一个架构良好的现代 PaaS 产品不论以公有还是私有 PaaS 形式（以内部部署形式托管）都应提供相同体验。在 PaaS 早期，当我们只有由 Google App Engine 和 Heroku 托管的服务时，为了满足规模上的运营效率，它们在应用设计上还有一些限制。但新一代关注企业的 PaaS 产品改变了这一情况。不论我们喜欢与否，混合云都将是未来一段时间的主流。现代 PaaS 产品试图缩短公有及私有 PaaS 间的差距，这样企业不仅可以从两种部署中获得优势, 同时获取不同托管版本。

在这方面，我想将 Docker 带入我们的讨论。随着容器的推广，不论 Docker 还是其它，私有和公有间的区别将会完全消失。我们不仅可以获取两个版本的类似环境，也可以在公有和私有 PaaS 间无缝地移植应用。在某些情况下，如果将多平台产品标准化到容器模型，很可能我们甚至能够在跨平台移植应用。

InfoQ**：PaaS似乎在其他“热点”概念中也被提及，比如：容器和 DevOps。你们是如何看待这些观点间的交互呢？**

Krish：对我来说，这很简单。PaaS 是 DevOps 和容器的推动者，是底层的标准化组件（针对某些 PaaS 产品）。

Dan：我认为你提到的所有概念都驱动着一个相同的目标：我们在努力改善业务服务交付。DevOps 是一种服务交付方式，它推荐了某些类型的流程，而不用指明这些流程是如何执行的。容器和 PaaS 在 DevOps 里都发挥着很好的作用，尤其当你想将 DevOps 概念调整到当前独立的企业 IT 商店时（当然说总比做起来容易）。

容器提供了一些很好的功能，包括便携性和应用隔离，可以满足众多企业的需求。但这只是平台应提供的一小部分功能，如 Krish 所说的，PaaS 供应商应考虑使用容器技术来完成这些目标。

PaaS 是一个相对比较完整的解决方案，尤其私有 PaaS 能促进 DevOps 的价值，哪怕是那些本身并非构建用以处理纯 DevOps 的企业。在这些情况下，平台可以作为通用语言将开发人员和运营人员组织在一起，确保最好质量的服务交付。

JP：在我的博文《Without A Strong PaaS, ITaaS, DevOps & IaaS Fall Short》里，我指出了一个很强的关联，它介于将 PaaS 作为渠道为客户交付常用共享平台和那些为 DevOps 制定设计、构建、测试、运行和终止（退役）相关 DevOps 管道的运营及开发。总的说来，PaaS 只是一个工具。跟所有的工具一样，其秘诀在于你怎么用它以获取你想要的结果。由于产品环境和开发环境的设置不同，多年来一直是低质量、停机和高成本的原因。PaaS 所提供的 IT 关注于以应用为中心，这就要求非 IT 相关事务具有敏捷性和高效性。它允许 Ops 关注于其服务的设计和交付以允许 PaaS 和应用开发专注其业务需求。而容器则是支持这一目标的完美工具，它为流程和数据提供了隔离，以允许开发 / 测试场景更简易的交付。

关于被访者

JM Morgenthal，用“企业 IT 之声”来形容他是最好不过的。他为技术应用以及在实际环境下为大中型企业交付的复杂性带来独特视角。他是一位有着 25 年经验的高级信息技术主管，是拥有技术的深度和广度以及强大的商业触觉的独特组合.JP 在云计算和集成领域是个知名作家和思想领袖。

James Urquhart，戴尔云管理器产品总监（前身为 Enstratius），该产品是混合云管理环境的先驱之一。James 一直是分布式系统技术专家，主要关注虚拟化、可拓展架构及云计算。James 曾被 MIT Technology Review、NextWeb 和 Huffington Post 提名为领先的云计算专家，James 经常为 GigaOm 撰写关于云计算和分布式系统趋势等方面的文章。

Dan Turkenkopf（@dturkenk）现在是 Tampa Bay Rays 的前端开发人员和分析师。在发现其梦寐以求的棒球队工作之前，他曾在 Apprenda，CGI 和 IBM 从事过应用云计算架构师。当前他与妻子，还有 4 岁的双胞胎住在纽约州萨拉托加温泉。在其难得的空闲时刻，他喜欢阅读系统复杂性方面内容，还喜欢编程，销售精酿啤酒，很难说他更喜欢哪个。

Krish Subramanian目前担任 Red Hat，OpenShift Strategy 的主管。在 Red Hat，他与 OpenShift 团队致力将旗下 PaaS 发展为主导性 PaaS 产品。在此之前，他是一名行业分析师及 Rishidot Research 创始人。他的关注领域包括平台服务、大数据和开源。