现在基于互联网的、运营租用服务的PaaS是第一代PaaS，PaaS还会进化到第二代。那时的PaaS将是更加标准化、私有云和混合云友好的PaaS，完全可用于企业IT系统的改造

云计算的时代，有太多的名词涌现，也有太多的概念被误读。PaaS（Platform as a Service，平台即服务）就是近来频频被提及的词汇之一。什么是PaaS？PaaS能做什么？

在分析过业界那些公认的、落地的PaaS（Force.com/Heroku，Google/App Engine，RightScale，Red Hat/OpenShift等）之后，您可能对PaaS有如下印象：

1. 这些PaaS在互联网上提供某种开发技术的运行环境，如PHP、Python、Ruby、Java。

2. 使用这些PaaS的开发人员不需要自行租用主机、申请域名、安装操作系统、安装数据库和中间件.

3. 和互联网IaaS一样，使用这些PaaS，要么免费，要么按时间、访问量、存储空间向用户收取租金。

如果你在业界颇有资历，可能会说“这和十年前诞生的VPS比有什么进步！不是新瓶装旧酒是什么？”。而另一边，那些著名咨询机构一直在为PaaS高唱赞歌：美林（Merrill Lynch）说“PaaS几年内可能会产生260亿美元的产业价值”，IDC预测“PaaS的争斗中会造就另一个微软”，难道都是忽悠?

这里我们来看看PaaS功能特性表象背后真正的精髓。特别的，我们不妨设想将PaaS理念从互联网应用“搬移”到企业应用研发环境后的结果。实际上，数十年来，形形色色的IT系统无非都在追求：成本控制、弹性、自动化、标准化和敏捷等。让我们看看PaaS带来的10种价值，看看它是让我们接近了这些理想，还是带来了新的问题。借此读者也许对PaaS的印象会产生一些改变。

表面上看，Runtime Fast Provisioning的好处仅仅是开发人员不用去安装运行环境，如数据库和中间件，节省的是学习成本和时间成本。事实上，为“标准化”带来的好处更多。试想，每个人对如何配置好一个优质的生产环境的见解是不同的，即使同一个人重复大量的配置工作也不能保证前前后后的一致性。稍具规模的开发组织和运维组织，多样化、不受控的运行环境对运维体系带来的挑战是巨大的。您也许会担心PaaS留给研发人员定制基础架构的途径不充分，您也许会抱怨现在互联网上PaaS的运维功能不友好，但别忘记PaaS一直在批评中进步，求取易用性和可定制性的平衡，这是主流厂商追求的方向和PaaS可以预期的目标。

由于PaaS的多租户特性，它的控制和管理一定是“网络化”和“集中式”的。对于公有云的PaaS用户，不一定能体会到集中统一管理带来的好处。但当我们最终将PaaS应用在私有云和混合云环境中，集中统一管理的优势便凸显无遗了。从前，管理层从开发和测试团队得到的信息总是“资源和环境不够用”，对有些服务器“正在干什么？”或“参与过哪次集成测试？”，这类问题有可能是没人知道的。经由私有PaaS的集中管控，研发和测试团队拿到资源的过程是快速的，而且对于管理者来说，使用情况是清晰的。管理员可以将用过的集成测试环境通过PaaS管理进行完整归档、快速恢复，减少对资源的长期占有。CIO一定会对触手可及的开发/运维环境机制，以及细致的资源利用率监测和充分利用爱不释手。

PaaS为研发带来的直接影响是，研发获得的是一个标准化的，为企业定制的一套研发环境和技术路线。在私有的PaaS环境中，开发人员个体在一定程度上“丧失”了对编程语言、技术框架、第三方依赖包自由选择的权力；与之对应，团队的管理者和咨询师获得了更强的对技术路线掌控的能力——所谓企业研发规范不再是一纸空文了。标准化、定制的研发环境带来的并非是死板和不灵活，而是实实在在的效率提升，以及不可控风险的减少。随着PaaS风格研发环境的引入，研发“个人英雄主义”的时代将会过去，团队的每个成员都按照既定的“游戏规则”实现软件功能，交付测试。同时，由于技术路线的简单化和对第三方依赖的梳理和减少，对团队新成员的培训成本也会大幅度降低。

很多CIO、CTO发现，“开源”的方向是企业应用研发的双刃剑。一方面，开源组件和开源基础架构很大程度上降低了构建应用所需的购买成本；另一方面，开源组件和基础架构却无形中增加了应用的维护成本。开源软件本身变化太快，缺乏很好的后向兼容与彼此兼容；开源软件良莠不齐，成功选型过多依赖于开发人员和架构师的经验……。诸如此类问题，让项目经理对开源始终抱着又爱又恨的态度。事实上，根据我们对PaaS的理解，PaaS实际上可以为开源在企业研发中合理的利用带来正确的途径。在PaaS中分析依赖，将研发环境实施标准化的过程，实际上也就是对开源技术进行审视、梳理、选择和测试的过程。同时，很多PaaS解决方案的提供商，如Spring Source、CloudBees、CloudEra和Red Hat，也提供开源组件和基础架构企业化的咨询。

企业IT决策者最为痛恨的是“厂商锁定”。所谓“厂商锁定”是指用户对某厂商专有产品和私有解决方案过度依赖的状况。厂商锁定抹杀了了用户选择的自由度，使得供求主次关系倒挂。同时，使用户的IT发展路线受制于厂商的产品路线与商业利益，与“IT基于业务增长而合理扩张”的正确方向相悖。PaaS方式的应用开发环境将会促成应用之于特定厂商软件技术（操作系统、中间件、数据库、私有API）的解耦合。随着一系列交互规范（包括云端API、数据操作接口以及Java EE接口规范）的不断成熟，软件基础架构的功能在PaaS平台上将渐渐走向同质化。由于可选择性的增多，厂商从功能层面去锁定用户就变得不太可能了。用户和研发组织能够选择标准化接口的基础软件去构建应用，然后部署在PaaS之上运行。

PaaS环境下，开发人员对底层资源（内存、进程、文件、网络）的访问能力是受限的。操作系统虚拟化或共享操作系统，无论采用何种途径实现PaaS，租户与租户之间的相互安全隔离是PaaS平台必须解决的问题。在实现上，可能通过底层虚拟化或IaaS有关技术解决；也可能在多租户共享操作系统的情况下，使用SELinux或cgroups等资源隔离技术解决。因此“安全性”是PaaS系统的固有特性。即使在PaaS建设初期缺乏安全性考虑，随后也可以通过简单一致的技术手段将其统一解决。企业CSO（首席安全官）也许很早就认识到，将操作系统和数据库的底层权限开放给研发人员决不是一个好主意，但却在项目与易用性需要的“残酷现状”下不得已而为之。有了PaaS与它先天提供的安全机制，针对开发人员的安全问题便可找到很好的途径解决。

SNA（Share Nothing Architecture）是高性能的互联网应用推崇的架构，基于SNA思想或REST风格构建的应用，有非常好的水平扩展特性。即应用的处理能力可通过增加服务器实例来线性的扩展，而不是靠增强单服务器的处理能力（CPU、内存、网络带宽）来进行有限的弥补。这样的架构风格成就了在多个低廉硬件支撑下并发访问量达数千万的互联网应用。由于源自互联网环境，PaaS环境下的很多基础服务天生就是支持SNA和REST风格的，例如数据网格、NoSQL、分布式文件系统等。依据这些基础服务，结合成熟的事务处理、分布式计算机制来构建企业应用，必将对传统的企业应用架构产生积极变革，“企业级应用=恐龙式的低性能应用”的状况会得到改变。价值8：智能负载均衡带来的健壮性

PaaS的一个非常吸引人的特性便是“智能负载均衡”。在理想的PaaS环境中，在访问量变化时计算资源能自动调节，不需要人工干预，并对最终用户透明。负载均衡/集群问题往往是困扰运维人员最主要的问题之一，首先是容量规划问题，有趣的是，在现实项目中最终回答这个问题的往往不是开发经理或测试人员，而是预算本身；而后是架构健壮性问题，从技术的观点来看，要同时做到高开发效率、高性能和高可靠性是比较困难的，甚至很多时候要实现这些目标是彼此矛盾的，它给架构师、开发人员和运维人员都带来了不小的挑战。很多时候，一个“看起来很健壮”，或“理论上伸缩性很好”的系统却经不起实际生产环境的考验。而PaaS从基础架构的层面带来了智能负载均衡和单点故障避免的最佳实践，分担了架构设计人员的忧虑，让他们更好地集中精力于业务实现本身。

“持续集成”和“自动构建”是重要的现代研发方法论，也是敏捷开发的精髓之一。而在企业的实际项目中，实现持续集成是有一定难度的，特别是在国内。现有的很多PaaS平台本身强制集成了持续集成的机制：开发人员的开发工作站仅仅是编写代码的场所，代码需要经由软件配置管理工具（subversion或git）推送到PaaS云端进行编译、构建、测试和发布；主流的PaaS平台集成了对持续集成系统（例如hudson、jenkins、continuum）的支持。基于这样的机制，通过强制的流程和手段，先进的软件开发与管理理论得到应用，软件质量和管理成熟度得到强制提高。项目经理能够每天看到自动构建的结果，从而了解到项目开发的真实进度，审查到快速迭代成品对需求的符合程度，达到“快速期望验证”的效果。除此之外，借助公有PaaS或混合PaaS，项目经理能够以非常低的成本验证软件产品的性能。他们可以在公有PaaS上快速租用上百个中间件和数据库运行实例，在几天内完成压力测试后退还，因为在PaaS环境中完成这样的任务花费很低，甚至还不到购买一台物理服务器的成本。

PaaS给企业开发和运维带来的不止是技术和方法上的变化，更重要的是有关组织架构和流程上的革新。传统的IT组织中，一般分为“研发”和“运维”两个职责团体。“研发”部门需要“运维”部门提供的基础架构来支撑和体现其劳动成果；而“运维”部门需要“研发”创造出的应用来实现业务价值。两个团体相互依赖，密不可分。但在现实中，这两股力量往往是相互不满、相互抱怨的——特别是在IT系统运转出现问题，不能满足服务质量保证时。我们设想，在PaaS的环境中，“研发”能够亲自负责“运行”生产环境，他们是应用的实现者，最了解自己编制的代码的特性，很多沟通的问题和复杂的人员交互流程消耗就可以避免了。而“运维”可以更加集中力量维护和扩展PaaS平台和IaaS平台本身，在一个可控的工作范围内提升服务绩效。新的人力分派和协作模式带来的效率提升是可以预期的。

回顾信息技术发展的不平凡的数十年，互联网计算环境和企业计算环境总是相互促进的。其中有技术上的影响，有架构上的影响，还包括最重要的对人的影响。所谓“云计算”，包括PaaS也盖莫能外。可以认为，现在基于互联网的、运营租用服务的PaaS是第一代PaaS，是网络大众参与、改造、提炼、淘汰的一种研发模型。待之羽翼丰满、优胜劣汰后，将产生第二代PaaS。那时的PaaS将是更加标准化，私有云和混合云友好的PaaS，完全可用于企业IT系统的改造。第一代PaaS影响互联网产业，第二代PaaS会给企业应用环境带来变革，其价值触动每位IT决策者的神经。