Web应用程序开发人员，在过去的20年中有两个选择：共享虚拟主机（容易的，但缓慢和不可靠的）或专用虚拟主机（困难的和不可靠的）直接做出选择。平台即服务（PaaS）不仅为Web应用程序开发人员提供了一个新的选择，它还为共享虚拟主机和专用虚拟主机提供了一个方便、快捷、可靠、可扩展的解决方案。
除了其他优点，主要内容包括：解释了核心云技术和供电的云应用程序（如Gmail、Dropbox）之间的区别，现实生活中的PaaS的案例研究，便携式和非便携式的PaaS系统之间的权衡指南，代码示例应用程序的变化，PaaS上的移动应用程序概述。

PaaS（平台即服务）正在对Web和移动开发者产生巨大的吸引力。但是，随着新PaaS供应商的出现，以及现有供应商对其产品特性的持续升级，要知晓PaaS可以提供什么就成为一件比较困难的事情。本书从开发者的视角对PaaS进行了透彻介绍，带领读者领略不同的PaaS模型，并且对Google App Engine、Windows Azure、Heroku、Cloud Foundry等供应商的不同类别的服务进行分解和分析。
本书全面展示PaaS如何帮助你专注于创造性的应用开发，而不是将时间花费在担心那些技术的运维问题上，不管你是创业家还是大型企业研发团队的成员，都会从中受益。
■ 介绍云从IaaS和DevOps到PaaS的发展轨迹。
■ 学习如何通过PaaS将共享Web托管的简便性和专有主机托管的可控性结合在一起。
■ 探讨可移植和不可移植PaaS方案的利弊。
■ 将最佳实践应用于迁移遗留代码到PaaS，并且理解这个过程中可能遇到的挑战。
■ 从头开始为PaaS编写REST风格的元服务。
■ 采用PaaS构建移动应用，并且通过后端服务进行扩展。
■ 审视主流PaaS供应商当前可以提供的核心服务。
■ 了解PaaS不能发挥作用的场合。

“本书以一种平实的方式帮助我完全理解了PaaS。”
——John Purrier
OpenStack共同创始人

Lucas Carlson创立了AppFog，这是一家于2013年被Century-Link收购的PaaS公司。作为一位拥有10年开发经验的专业开发者，Lucas专注于Ruby on Rail的开发。他还是《Ruby大全》的合著者，并且用不同的编程语言创建了6个库。

编程很艰难
编程是一项很艰苦的工作。相当艰苦。当你完成代码编写并且编译成功，你很开心。可是你会发现程序存在bug，这耗费了你几小时、几天、甚至几周时间去查找、定位、解决这些问题和边界情况。当你完成所有编码并且认为不会再有更难的问题了，你还得部署代码：Vim apache.conf.vim my.cnf.vim /etc/host.iptables。当你觉得你是一个程序员时，突然你深深陷入了系统管理的泥潭中，完全不明白怎么会这样。
程序员比较擅长的事是创造性的偷懒。当一个程序员重复做同一件事情时，总有一天他会想：难道我的电脑无法帮我完成吗？大概在2005年，世界上很多程序员的改编使得apache.conf文件变化巨大。几位杰出程序员决定他们再也不愿意这样继续下去。
DevOps和PaaS两种模式的横空出世改变了应用部署模式。DevOps对apache.conf文件编辑工作的回应是：我可以编写代码模板（称为技巧或者大全）来帮我完成系统管理。PaaS对apache.conf文件编辑工作的回应是：我能编写程序来帮我进行系统管理。于是很多关于DevOps的好书问世了，例如Dan Bode和Nan Liu合著的《Puppet Types and Providers》 或者Stephen Nelson-Smith写的《Test-Driven Infrastructure with Chef》，但是几乎没有关于PaaS的书。
PaaS很棒！你在专有主机上获得的好处（例如每个应用都运行在自己的进程并系统负载均衡）在共享主机上能轻松获得（你不需要做任何配置管理，PaaS替你完成了）。但是这些好处是有代价的。你必须编写能够在PaaS环境下运行的代码。
编写PaaS代码
很多书籍没有涉及这个主题：哪个编程模式最适合于PaaS以及哪个反模式不再适用于PaaS环境？这就是本书的核心内容。虽然PaaS的流行度以指数级增长，以至于世界上百万计的开发者已经接受PaaS，数百万人开始学习它，但并没有多少书面资料可以用于指导开发者们如何成功地将PaaS最佳实践应用于他们的编码过程，以发挥PaaS的最大功效。
具体地说，当下很多开发者们面临的最大挑战之一就是如何将遗留代码和旧应用移植到PaaS模式下。几乎没有这方面的资源指引他们战胜挑战，希望这本书提供的资讯交流能给读者正确的指引。
本书读者对象
这本书是写给那些想要更多了解平台即服务（PaaS）的程序员、开发者、工程师和架构师的。
当然，对于非程序员来说，也可以从本书中发现价值。实际上，如果你正想要说服你的老板在公司内部使用PaaS，你可以给他看这本书。或者，你可以去本书第8章里找关于PaaS利弊的一些资料跟老板讨论。这会让老板觉得你是认真思考过这个问题并得出了一个有理有据的观点，而不仅仅是随波逐流。
在有些技术章节，我甚至给出了代码样例。既然PaaS可以与很多编程语言协同工作，因此我提供各种编程语言的简单样例，包括PHP、Ruby、Node.js、Java，以及Objective-C。我们没有深入介绍任何一种语言，而是在相对较高的层面上进行讨论，因为我们希望你能熟悉一到两种并能读懂其他的语言。
本书组织结构
如果你是一位架构师或者技术管理者，或者刚开始接触PaaS，前三章对于理解PaaS技术背景非常重要。这些章节阐述了什么是云（第1章），PaaS是什么（第2章），以及不同PaaS技术及相对的优缺点（第3章）。
如果你已经了解PaaS的历史或者已经使用过某种PaaS平台，你可以粗略浏览前三章，仔细研读接下来的第4～6章。这几个章是本书的核心，提供了实际有效的工具、方法和编程模式来帮助你远离PaaS编程中的重大误区，少在编程反模式上浪费时间。
第7章是每个人都需要重点理解的一章。数据库服务和缓存服务或者邮件服务囊括了PaaS中的一些重要注意事项。如果不细心的话，这些就是采用PaaS时最容易出错的地方。
接下来的两章回到对那些行而上学的问题的讨论上，以加深理解。第8章讨论了全盘采用PaaS是否恰当，包括优点和缺点。明白PaaS是否适合你正在处理的问题是至关重要的。第9章的讨论围绕着PaaS的发展方向、一些行业发展趋势，以及关于PaaS领域开源运动的思考。
最后一章介绍了跟PaaS相关的所有可用的技术，因此可以给大家提供很好的参考。你应该在第10章放置一个书签，因为你可能会要翻到这章去发现一些灵感和观点，因为这里介绍了所有类型的服务提供者和技术（PaaS、IaaS、SaaS和有用的代码库）。
本书的约定
本书使用了以下排版约定：
斜体（Italic）
用于新术语、URL、电子邮件地址、文件名与文件扩展名。
等宽字体（Constant width）
用于表明程序清单，以及在段落中引用的程序中的元素，如变量、函数名、数据库、数据类型、环境变量、语句、关键字等。
等宽粗体（Constant width bold）
用于表明命令，或者需要读者逐字输入的文本内容。
等宽斜体（Constant width italic）
用于表示需要使用用户提供的值或者由上下文决定的值来替代的文本内容。
注意： 表示一个技巧、建议或一般性说明。
警告： 表示一个警告或注意事项。
示例代码的使用
本书提供代码的目的是帮你快速完成工作。一般情况下，你可以在你的程序或文档中使用本书中的代码，而不必取得我们的许可，除非你想复制书中很大一部分代码。例如，你在编写程序时，用到了本书中的几个代码片段，这不必取得我们的许可。但若将O扲eilly图书中的代码制作成光盘并进行出售或传播，则需获得我们的许可。引用示例代码或书中内容来解答问题无需许可。将书中很大一部分的示例代码用于你个人的产品文档，这需要我们的许可。
如果你引用了本书的内容并标明版权归属声明，我们对此表示感谢，但这不是必需的。版权归属声明通常包括：标题、作者、出版社和ISBN号，例如：“Programming for PaaS（O扲eilly）. Copyright 2013 Lucas Carlson and Doug Baldwin, 978-1-449-33490-1”。
如果你认为你对示例代码的使用已经超出上述范围，或者你对是否需要获得示例代码的授权还不清楚，请随时联系我们：permissions@oreilly.com。
联系我们
有关本书的任何建议和疑问，可以通过下列方式与我们取得联系：
美国：
O'Reilly Media，Inc.
1005 Gravenstein Highway North
Sebastopol，CA 95472
中国：
北京市西城区西直门南大街2号成铭大厦C座807室（100035）
奥莱利技术咨询（北京）有限公司
我们会在本书的网页中列出勘误表、示例和其他信息。可以通过http://oreil.ly/programming-paas访问该页面。
要评论或询问本书的技术问题，请发送电子邮件到：
bookquestions@oreilly.com
想了解关于O'Reilly图书、课程、会议和新闻的更多信息，请访问以下网站：
http://www.oreilly.com.cn
http://www.oreilly.com
还可以通过以下网站关注我们：
我们在Facebook上的主页：http://facebook.com/oreilly
我们在Twitter上的主页：http://twitter.com/oreillymedia
我们在Youtube上的主页：http://www.youtube.com/oreillymedia
致谢
首先，我想要感谢Doug Baldwin协助整理书稿，如果没有他这本书将无法完成。
如果没有Meghan Blanchette的耐心和坚持以及Mike Loukide的信任，我将永远不会开始或者完成这本书。
感谢Kara Ebrahim、Meghan Connolly以及O扲eilly所有成员，你们的努力让本书得以呈现！
如果没有技术审核员，这本书的质量将难以这么完美，他们发现了很多缺陷、问题和概念上的错误，他们是：John Purrier、Alex Parkinson、Larry Hitchon、Andrei Matei、Chad Keck和Troy Howard。
谢谢我的妻子、儿子、女儿、爱犬、妈妈、爸爸、兄弟等，谢谢你们一直以来的支持和爱。
最后，感谢创造了PaaS的程序员和发明者，以及支持他们的公司，谢谢你们让我们的生活变得更简单。

计算机\程序设计

“本书以一种平实的方式帮助我完全理解了PaaS。”
——John Purrier
OpenStack共同创始人

平台即服务（PaaS）正在对Web和移动开发者产生巨大的吸引力。但是，随着新PaaS供应商的出现，以及现有供应商对其产品特性的持续升级，要知晓PaaS可以提供什么就成为一件比较困难的事情。本书透过一个开发者的视角，对PaaS进行了透彻介绍，带领读者领略不同的PaaS模型，并且对Goog App Engine、Windows Azure、Heroku、Cloud Foundry以及其他供应商的不同类比的服务进行分解和分析。
不管你是创业家还是某个大型企业研发团队的成员之一，本书都将会为你展示PaaS如何帮助你专注于创造性的应用开发，而不是将时间花费在担心那些技术的运维问题上。

·介绍云从IaaS和DevOps到PaaS的发展轨迹。
·学习如何通过PaaS将共享Web托管的简便性和专有主机托管的可控性结合在一起。
·探讨可移植和不可移植PaaS方案的利弊。
·将最佳实践应用于将遗留代码迁移到PaaS，并且理解这个过程中可能遇到的挑战。
·从头开始为PaaS编写REST风格的元服务。
·采用PaaS构建移动应用，并且通过后端服务进行扩展。
·审视主流PaaS供应商当前可以提供的核心服务。
·了解PaaS在哪些场合下不能发挥作用。

（美）Lucas Carlson 著：Lucas Carlson 创立了AppFog，这是一家于2013年被CenturyLink收购的PaaS公司。作为一位拥有10年开发经验的专业开发者，Lucas专注于Ruby on Rail的开发。他还是《Ruby大全》的合著者，并且用不同的编程语言创建了6个库。

潘黎萍　余水清　译：暂无简介

智能设备和互联网应用的日益普及诞生了一系列层出不穷的新概念和新技术，以满足日益增长的数据量和人们的计算需求。云计算无疑是其中非常吸引眼球的技术之一。
然而，即使是从事云计算相关研究和开发的人员也不一定能区分清楚云计算到底有哪些相关技术，其背后的发展历史是怎样的，以及未来的发展方向。因此，虽然云计算这个概念被IT厂商、开发者以及各种规模的企业热炒了数年，但真正落地并开花结果的还真的不多见。
作为一名资深的开发者，Lucas Carlson无疑见证了应用开发架构的发展历程，从构建简单的网站，到创建AppFog这一基于Cloud Foundry的平台即服务公司，这一切促成了他对云计算平台的深入了解。因此，本书作者基于他自身的深切体会和资深的开发经验，论述了PaaS技术的发展历史、各类PaaS平台技术的优缺点、如何向PaaS上迁移遗留应用、如何开发新的PaaS应用、什么情况下可以采用PaaS以及什么情况下不能采用PaaS等一系列的问题。无论对于新接触PaaS还是已经采用了PaaS一段时间的资深人士，都可以从这些话题的论述过程中进一步加深对PaaS的理解。

前言 1
第1章 开发者的云 7
1.1 开发者的困境 8
1.2 云能为创新做什么 8
1.3 云：发展历程简介 9
1.4 云的核心技术 14
1.5 管理平台与产品化平台 15
1.6 云计算的承诺（或者炒作） 16
1.7 云技术的未来5年 16
1.8 兑现承诺 17
第2章 什么是PaaS 18
2.1 魔术网站 18
2.2 开发者早期的选择 19
2.3 PaaS：综合两种方式的最佳方案 24
2.4 PaaS：现代应用的虚拟工具 28
2.5 重建信心 29
第3章 PaaS类型 30
3.1 不可移植的PaaS：遵照一个模板 30
3.2 可移植性：不再繁琐 33
3.3 走向公开标准 39
第4章 遗留应用迁移到PaaS 41
4.1 初步考虑 41
4.2 概述 43
4.3 资产托管 44
4.4 会话管理 49
4.5 缓存 52
4.6 异步处理 56
4.7 SQL 57
4.8 NoSQL 58
4.9 各种陷阱 59
第5章 在PaaS上开发新应用程序 61
5.1 分解庞然大物 61
5.2 将API应用于移动开发 63
5.3 JSON和REST的出现 64
5.4 使用基于REST的元服务 69
5.5 PaaS的独特贡献 72
5.6 摩尔定律的影响力 74
第6章 PaaS上的移动应用 76
6.1 移动应用开发简史 76
6.2 未来应用 77
6.3 数据结构 78
6.4 调用移动客户端的元服务 79
6.5 PaaS如何让移动后端开发更容易 83
6.6 服务于更多用户 85
第7章 核心服务简介 86
7.1 非PaaS核心服务 86
7.2 评估PaaS服务 87
7.3 采用托管的数据库和PaaS以节省时间 88
7.4 缓存和PaaS: 冗余 92
7.5 解决Email的挑战 93
7.6 监控的重要性 94
7.7 负载测试 96
7.8 计划升级途径 96
第8章 为什么不选择PaaS 100
8.1 公共云与私有云 100
8.2 中小型公司：如何选择 101
8.3 大型企业级用户：如何选择 103
8.4 PaaS的限制 103
8.5 直面阻力 107
8.6 以长远的视角看待限制 108
第9章 PaaS的未来 109
9.1 OpenStack的影响 109
9.2 保持开发选项的开放 110
9.3 故障：开发者必须面对的最大问题 111
9.4 通过开源重新获取控制 112
9.5 最终的思考 115
第10章 资源 116
10.1 PaaS供应商 116
10.2 IaaS供应商 119
10.3 托管服务 120
10.4 将遗留应用迁移到PaaS 123
10.5 新兴PaaS应用开发 124