前 言
编程很艰难
编程是一项很艰苦的工作。相当艰苦。当你完成代码编写并且编译成功，你很开心。可是你会发现程序存在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环境下运行的代码。
目 录
第1章 开发者的云
1.1 开发者的困境
1.2 云能为创新做什么
1.3 云：发展历程简介
1.4 云的核心技术
1.5 管理平台与产品化平台
1.6 云计算的承诺（或者炒作）
1.7 云技术的未来5年
1.8 兑现承诺
第2章 什么是PaaS
2.1 魔术网站
2.2 开发者早期的选择
2.3 PaaS：综合两种方式的最佳方案
2.4 PaaS：现代应用的虚拟工具
2.5 重建信心
第3章 PaaS类型
3.1 不可移植的PaaS：遵照一个模板
3.2 可移植性：不再繁琐
3.3 走向公开标准
第4章 遗留应用迁移到PaaS
4.1 初步考虑
4.2 概述
4.3 资产托管
4.4 会话管理
4.5 缓存
4.6 异步处理
4.7 SQL
4.8 NoSQL
4.9 各种陷阱
第5章 在PaaS上开发新应用程序
5.1 分解庞然大物
5.2 将API应用于移动开发
5.3 JSON和REST的出现
5.4 使用基于REST的元服务
5.5 PaaS的独特贡献
5.6 摩尔定律的影响力