微信号:infoqchina

介绍:有内容的技术社区媒体

【对话】虚拟圆桌:云计算中PaaS的未来

2014-06-05 20:28 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 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 不惧裁员停招!抵御互联网寒冬,2015最后一战! 开发者政策中心 | 商品详情和宣传 pt-osc改表导致数据不一致案例分析 为什么你说“就差一个码农了”,我们是拒绝的 Scoops android app多主题架构(四)