想开发云应用程序？先选择合适的PaaS！

从一个方面来分析，开发云应用程序的平台即服务模式有两种：一种是专用模式，托管在本地或私有云中;另一种是公共模式，由第三方提供商来托管，并采用订阅支付模式。那只是问题的一个方面。还可以以一种全然不同的方式来分析PaaS：这种方式基于与云环境的联系。

据长期的IT和云计算顾问Judith Hurwitz声称，从这种联系的角度来分析PaaS，会发现存在两种不同的模式。其中之一是，PaaS与某个特定的软件即服务(SaaS)环境联系在一起，比如Salesforce的Force.com和Heroku Enterprise。另一种是PaaS受制于某个特定的云操作环境，以亚马逊网络服务(AWS)的Elastic Beanstalk为代表。另外还有可以自由添加的PaaS解决方案，它们并不与任何一个云联系在一起。这些包括Apprenda、CloudBees、Engine Yard及其他PaaS解决方案。

随着公众对云提供商安全的信心不断加强，对PaaS的依赖程度也随之提高，用于开发云应用程序。虽然PaaS支出仅占总体云环境的一小部分，但正以惊人的速度增长。MarketsAndMarkets公司在最近一项研究中预测，到2018年，全球PaaS市场会增长到69.4亿美元，而五年前还仅仅只有12.8亿美元DD年复合增长率高达32.54%。

作为Hurwitz提出的两种模式中的第一种，将PaaS绑定到SaaS让提供商得以“通过提供一个完整的、受保护的生态系统，延伸品牌，”她说。“这是独立软件开发商或企业开发人员构建旨在完全在该环境中运行的自定义应用程序的最容易、最快速、最安全的方式。”这不是什么新的想法：2011年DD按云计算行业的标准来看那已是很久以前，Workday发布了自己的受制型PaaS，采用的品牌名是Workday集成云平台(Workday Integration Cloud Platform)。这家公司位于加州普莱森顿，专门开发基于云的人力资源和财务管理应用软件。

在第二种模式中，PaaS解决方案与整个云操作环境、而不是与某个特定的应用服务紧密联系起来。她说：“如果你打算编写只在AWS、微软Azure或IBM Bluemix上运行的应用程序，选择它们的PaaS解决方案是合理的选择。”她表示，比如说，如果某家企业组织在.NET框架方面有扎实的专长，或者有一大批应用程序在使用.NET框架，那么选择微软的Azure开发和部署生态系统将是自然而然的选择。

据Hurwitz声称，这个PaaS领域势必会出现重大变化。她说：“虽然我们仍然看到与某个特定平台绑定的PaaS解决方案，但现在我们更多地看到Pivotal的开源Cloud Foundry受到追捧，作为实施PaaS的一种标准方法。” EMC旗下的VMware部门在2011年推出了Cloud Foundry。两年后，EMC将那些资产作为Pivotal Software拆分出来。

Dave McCrory是Basho科技公司的首席技术官，这家公司专门开发Riak开源数据库。他表示，想选择合适类型的PaaS来开发云应用程序，关键因素是了解手头的项目。没有哪一种类型的PaaS适合所有情形，而这势必需要开发人员的工具包中同时有几个PaaS。

McCrory说：“由于应用程序开发场景不同，所以有众多不同的PaaS类型。”他赞同Hurwitz的观点，表示一种就是SaaS式样，以Force绑定到Salesforce这种方式为代表。他表示，Heroku不一样，就在于“你上传想要运行的各个组件，然后将应用程序上线。它并不像Force那样紧密地绑定到Salesforce。”

McCory表示，其他PaaS解决方案允许开发与基础设施更紧密结合的云应用程序，他提到Mesosphere就是个例子。“这是一种PaaS式样的服务，更接近网络物理层。”

最近云计算领域新增的一个角色是AWS Lambda，它自称是“构建和运行云端应用程序的一种全新方式。”McCrory表示，虽然它不是典型的PaaS，但基于这个想法：编写极小的代码片段，以便将其他小小的代码模块连接起来。McCrory说：“你不是构建一个庞大的程序;相反，你是构建一系列小小的组件。” McCrory表示，与其他PaaS模式一样，其目的也是加快开发、简化维护。

无论最终选择哪种类型的PaaS来帮助开发人员加快开发和部署，McCrory表示，仍要认识到PaaS只是整个开发环境里面的一个组件而已，这点很重要。他说：“当前的趋势就是，拥有从头到尾的综合工作流程、实现测试和部署自动化，即从基于云的IDE(可以在其中编写代码)，到源代码库(比如GitHub)。”

McCrory表示，对于开发人员来说，转移到PaaS模式最终是为了加快开发应用程序和更新应用程序(一旦部署到生产环境中)。“优点在于，你不需要升级庞大的整体式应用程序，而是只要进行小幅的增量变化。”

系统可能顺畅地运行几个月，结果却在软件变化后出现崩溃，无论是大变化还是小变化。推特已经在2016年1月出现停运，几乎遍及全世界，公司将这六小时的停运归咎于“内部的代码变化”。后来代码回滚消除了那个问题。McCrory说：“如果你在更新后遇到了问题，若使用PaaS模式，可以轻松回滚，并检查导致问题的增量变化。这要比另一种方法：六个月的升级周期好得多，因为那样可能进行了数千处变化，你在查找导致问题的代码时，可能要停运好几天。”