在线客服
平台即服务(PaaS)是一种新的横向扩展型平台，便于开发、测试和部署应用程序。它可供公有云和私有云使用，为多种编程语言提供了可扩展性、敏捷性和支持。
早在2011年，斯坦福大学的两位研究生Bobby Murphy和Evan Spiegel灵光乍现，对文本消息有了精辟的认识：堆积的文本消息是个严重问题。Murphy和Spiegel从朋友那里听到了一个个的故事：由于被不 该发现的人发现了仍敞开的可读消息，结果搞砸了关系、败坏了声誉、丢掉了饭碗。他们于是想到了开发Snapchat，这个应用程序可以迅速忘记通过它传送 的所有消息。
决定开发这个应用程序很容易，不过实际构建应用程序却很难，如果他们俩走这条传统路子：买来服务器在后间搭建服务器，那就更困难重重。仅仅为了维护网站服务器、内容分发网络和数据库顺畅运行，他们俩就需要一个团队。而这在当时不可能。
于是，Murphy和Spiegel决定求助于谷歌应用引擎(Google App Engine)，这个框架可以将应用程序必不可少的所有基础设施组合到一个产品中。这个PaaS(平台即服务)让他们能够致力于为应用程序编写逻辑，而这 个框架处理安全存储数据和高效管理交付方面的细节问题。
如今，Snapchat的用户多达数百万。不过，这家公司仍然很小，只雇有几十名员工。该公司的小规模很有迷惑性，因为在某种意义上，从事谷歌应用引擎开发的所有谷歌人员也是其团队的一员。
如今，成千上万个应用程序构建在众多PaaS解决方案上。其中一些应用程序依赖PaaS满足几乎各个要求，而另一些应用程序只使用几项功能特性，依 赖专有的软件堆栈来满足其余要求。不过最终，每个PaaS提供了一样的东西：一个完整的环境，便于开发、测试和部署应用程序。PaaS提供了一种服务丰富 的高可用性平台，另外还有两大优点：云可扩展性以及(在大多数情况下)支持多种语言。
PaaS的优点和弊端
动态扩展能力至关重要。如果新的客户大批量涌现，计量体系要运转得更快。如果需求因某个产品或服务很流行而激增，这家服务公司就进入上升通道。应用开发人员没必要为核心应用程序之外的任何东西而操心。
许多PaaS解决方案只在公有云中运行，包括Amazon Elastic Beanstalk、CloudBees、Force.com、谷歌应用引擎、Heroku和Windows Azure――更不用说诸如Parse之类的MBaaS(移动后端即服务)解决方案了。公有云PaaS的用户往往依赖软件开发商(比如Netflix或 Snapchat)，这类软件开发商构建和部署面向公众的Web或移动应用程序。
然而，企业开发人员通常更喜欢在内部开发和部署应用程序。他们可以使用所谓的“企业PaaS”解决方案，包括Active State Stackato、Apprenda、Pivotal Cloud Foundry、Progress Pacific和红帽OpenShift。虽然PaaS驻留在企业数据中心，但它提供了使用大众化硬件的同样的横向扩展型架构。
无论公有还是私有，所有PaaS解决方案都有许多共同的特点。下面介绍其中两个最重要的特点:
API
PaaS解决方案(公有云或私有云)都随带自己的一套API，可用于访问数据和各项特性。如果这些预制的API以一种合适的方式提供开发人员所需要 的一切，那它们很好。要不然，就会出现挑战。服务提供商不可能必写每个应用程序来迎合每个客户。而如果服务提供商决定改变API，可能与你的应用程序保持 向后兼容性，也可能不是这样。
如果是内部部署型企业PaaS，你不会受到可能导致应用程序无法正常运行的API变化。私有PaaS还为你提供了更大的灵活性，因为你可以配置自己的API，以便本企业中的服务进行会话。一旦这项工作完成，私有PaaS上的所有应用程序都能充分利用那些API。
开发和部署工具
在许多情况下，PaaS仅仅提供了用于测试、部署和管理应用程序的平台。至于实际的代码编写工作，开发人员通常使用本地机器，像平常那样上传代码。除了自助服务和动态横向扩展功能外，与传统应用服务器最大的区别就是，运行时环境支持多种语言。
然而，一些PaaS解决方案实际上包括集成开发环境(IDE)――或者在一些情况下，甚至让非开发人员也能够使用可视化应用程序开发工具来组装应用程序。这些工具很适合一些应用程序，但是经验丰富的编程人员往往更喜欢自己的工具，很可能会觉得预定义的工具功能有限。
一大好处是与Git和Jenkins集成，管理软件版本控制和持续集成。此外，一些PaaS解决方案包括提供了某种应用程序生命周期管理机制的工作流程工具。这相当有用，尤其是在组织管理多个应用程序开发项目时，但是它们需要异常灵活，足以适合目前的流程。
PaaS方面要考虑的问题
为你的应用程序选择合适的PaaS需要全面评估自己的要求。如果你构建的是仅仅交换短暂状态更新的轻型应用程序，可能不需要事务符合ACID(原子 性、一致性、隔离性和持久性)的复杂数据库。不过，一个银行应用程序需要牢不可破的SQL数据库，有异地备份，还要有一整套报告工具确保一切都受到了追踪 和审计。
一旦你大致了解了想要构建的应用程序，就要问清楚这些问题：
这家公司的生存能力多强?
这个问题主要适用于公有云PaaS提供商。一旦你选择了PaaS，你可能会被提供商锁定，具体取决于你使用的PaaS的特定功能。如果PaaS被收购或破产，你辛辛苦苦的工作成果可能转移不出去。这种依赖性可能是许多企业不太愿意选择公有云PaaS的主要原因。
哪些语言得到支持?
有几个PaaS解决方案相当专业化，其中大多数是在公有云。比如说，Salesforce的Force.com只支持其自己的类似Java的语言 Apex，而CloudBees仅仅面向Java开发人员。然而，一个总的趋势是扩大支持语言的种类。红帽OpenShift目前声称覆盖范围最广，支持 Java、Node.js、Ruby、Perl、PHP和Python等语言。
提供哪些数据库?
几乎每一个公有云PaaS都提供MySQL数据存储区;许多还提供PostgreSQL。这年头，你还有可能找到支持MongoDB等NoSQL数 据库的功能。NoSQL工具通常提供更高的性能和更灵活的架构，可以支持迅速演变的应用程序。比如说，很容易为一些记录添加新字段和特定数据块，开发人员 还能迅速适应新需求。
虽然NoSQL数据库的周转时间短，但缺点是确保数据一致性方面相对缺乏保障。数据通常正确存储和检索，但是奇怪的差错或崩溃有时会带来错误和故障。对社交网络应用程序而言，这种缺点可以接受，客户可以原谅偶尔出现的故障。
SQL数据库提供了较可靠的机制，确保数据一致性，因而对使用关键任务型数据的复杂应用程序来说具有更大的吸引力。这种数据库更成熟，常常能够支持功能更丰富的分析和报告。
平台提供一些备份和镜像也很常见，而且常常横跨大片区域。关键任务型数据可以自动存储在世界上不同地区，那样万一发生重大事件，就能提供弹性。
改换有多容易?
不是说与每家提供商都能保持永久的关系。有时候，一段时间后，提供商满足不了你的要求。有时候，你的要求会变化。有时候，改换新平台很容易，有时则 不然。所有平台都会带来某种程度的锁定现象，因为仅仅迁移和重新配置很麻烦――但是有些迁移起来比另一些更困难。一些提供商使用Linux和 Windows的自定义版本;另一些拥有专有层，一旦你离开，会迫使你改写所有的自动化代码。
最大的障碍就是专有的语言包和API。如果你使用某一家提供商的一些服务，如果你想换成另一家提供商，可能不得不改写这些代码，因为两家的API会 不一样。这可能是积极采用一些最复杂的工具和服务面临的一个重大的、又常常隐藏的风险。一旦你选择了它们，围绕它们构建你的应用程序，切换成本就会相当 高。
你能运行自己的副本吗?
企业PaaS解决方案在你自己的数据中心运行，提供了更高的安全性、灵活性和控制性。不过切记：在大多数情况下，你需要将PaaS部署到自己的私有 IaaS基础设施(比如OpenStack或VMware的vCloud)上，才能获得可扩展性的全部好处。在一些情况下，PaaS提供商同时提供公有云 版本和内部部署型版本;这样一来，就很容易在两者之间迁移应用程序。在这种混合场景下，你可能将不大敏感的信息移到公有云，将比较重要的数据保留在自己的 数据中心中。
是否有足够的支持?
PaaS可以为你节省大量的时间和精力，但是它无法为你编写应用程序。你需要逐渐深入了解产品，找到使用API的最佳方式。最优秀的公司提供了在线 说明文档和示例代码。比较好的公司定期提供课程，以便用户了解基础知识。在线支持必不可少。一些最优秀的公司还提供工程师，他们可与你的项目团队合作，甚 至编写一些最复杂的代码。
最前沿的差异化优势
大多数PaaS提供商提供一样的基本的大众化服务，用于存储信息、构建和部署应用程序。最优秀的提供商在添加下一层特性，以便为客户简化工作。这些额外特性值得一提，因为它们对于部署速度大有影响，如果你重新构思应用程序，它们还能适应变化。
插件生态系统：没有哪家服务提供商能开发出满足每个人要求的系统。一个稳定成熟的插件生态系统让别人编写的代码能够为你的应用程序添加功能。某些插件对一些任务来说必不可少，这取决于你是什么样的用户和所处理的任务。
一些用户依赖插件存储和检索来自其他云中其他服务的数据，以此扩大应用程序的积极影响。比如说，他们可能将备份副本发送到远地云，或者可能依赖转换工具，比如在线外语翻译工具。其他用户使用插件来增添另外的合规逻辑层，以便筛选审查进入系统的数据。这方面有许多选项。
这些工具的复杂性对服务和用户来说都是个挑战，因为插件开发人员实际上成了编程方面的合作伙伴。如果用户犯了错误或者造成死循环，整个服务就可能岌 岌可危。同样道理，用户必须依赖插件，才能在与PaaS本身相符的层面交付服务。如果双方都为这个过程投入了足够多的时间，这可能是富有成效的合作关系。
大数据探查：由于越来越多的应用程序依赖复杂的分析，一些服务提供商在提供复杂的统计数据处理工具。比如说，音乐服务依赖统计模型来推荐新歌。
优秀的数据分析工具是PaaS脱颖而出的一个方面。一些在构建可供这项任务租用的Hadoop集群。另一些在为内置到数据库层的报告程序包添加更复杂的分析功能。最优秀的工具提供了复杂的统计模型，它们能够适应装入数据的响应，让系统功效大大增强。
事件处理：许多Web应用程序很复杂，结合了数据库更新信息和数据转换。点击一下应用程序，就会触发一连串动作：数据从一个机器流动到另一个机器，从一项服务流动到另一项服务。
控制这多个步骤的一个好办法就是，事件管道或消息传递服务。这种工具安排安在机器之间流动的消息，让编程人员没必要处理棘手的通信问题。一旦数据库 更新了事务信息，数据库就会向数据仓库发送一个新的事件，附有发送方面的信息。这一连串事件有效地将大批服务连接起来。应用程序用户可能只要按一下按钮， 就会触发精心设计的按顺序操作的事件，它们让许多服务可以协同运行。如果为你做好了事件传递工作，开发优秀的应用程序要容易得多。
安全性和可用性：编程人员往往对安全性和可用性问题习以为常。这是PaaS本身必须内置安全性的一个原因。如果系统出现故障或泄漏重要信息，可能会 酿成严重后果。你可能期望企业级私有PaaS与传统的企业目录和验证系统集成起来，并提供基于角色的访问控制。公有云PaaS提供商还在添加安全层，在一 些情况下，针对资源使用，提供异常精细化的控制。
弹性、冗余性和高可用性是PaaS的几大关键特点。PaaS本身在设计时应该能经受得住基础设施层面的故障，并提供分布式机制，那样万一出现孤立的服务器、存储或网络故障，照样能确保平台服务顺利运行。
安全标准：一部分安全和合规标准包括如下：FIPS 140-2(联邦信息处理标准)、ITAR(《国际武器贸易条例》)、ISO 27001、PCI DSS Level 1(支付卡行业数据安全标准)、FISMA Moderate(《联邦信息安全管理法案》)和SOC 1/SSAE 16/ISAE 3402。如果你的应用程序要处理敏感的个人数据或交易数据，更需要PaaS提供商遵守一整套标准。虽然标准本身并不是万无一失的保障，但是它们充分证明 了工作人员在关注细节，并制定了一套增强安全的体系。
访问控制：服务提供商提供许多不同的解决方案来控制对PaaS及工具的访问。最复杂的方法使用公钥加密技术，对针对重要变化的所有请求进行签名。对服务的访问则使用SSL和SSH来加密所有通信，确保只有拥有相应私钥的人才能进入系统。
不是所有事件都需要此类措施。针对一些API的较简单请求使用更灵活更高效的令牌来限制用户。令牌还用来衡量一些计量服务的使用情况。
故障追踪和SLA：虽然所有服务提供商都旨在获得最佳结果，但是错误和异常难免会发生。最好的服务密切追踪故障，那样用户和公司就能尽量减小故障引起的麻烦;有些服务提供记录服务故障或异常的公共网页。
大多数PaaS提供商还提供服务级别协议(SLA)，保障正常运行时间或性能达到一定的级别;如果实际提供的服务未达到指定级别，提供商就会给予退 款或积分。在云领域，SLA往往是分层次的，较高的服务级别收取较高的费用。如果某应用程序很重要，万一发生严重故障，提供商再怎么弥补可能都无济于事。 这是全面审查PaaS提供商的又一个原因。
PaaS迎来爆炸性增长
如今，如果开发团队坐下来计划开发一个新的应用程序，他们常常期望获得Snapchat那样的发展。这家公司声称，它每天处理的“snap”(该术语指短暂的文本消息)多达上亿个。文本消息进来后，公司存储起来，有人读取后，它们就会消失，从此不会再次看到。
要是没有一个优秀团队在处理繁重任务，Snapchat不可能从一无所有，变成每天处理数亿个文本消息。虽然Snapchat依然规模很小，但他们利用了整个应用开发团队的能力和洞察力。
如今的开发团队有好多选择，许多团队在竞相提供最灵活的最佳服务。现在正是你将作为简单服务而提供的复杂基础设施连接起来，发挥创造力的大好时机。
（文章选自云头条编译）
返回上一页