起因
PaaS作为“云”的概念，已经流行了很久。从使用的角度上看，似乎就是：写一个PHP，然后可以直接传到服务器上，用户就能通过某个URL访问你写的PHP了。——这确实极大的节省了开发和运维的工作量，因为这几乎完全不用去部署安装任何服务器端的软件，甚至数据库也给你装好了。但是因为各种各样的原因，在国内PaaS的使用并不非常广泛，有可能是因为没有好的服务提供商（由于伟大墙的原因导致某些服务无法访问）。另外，作为一个游戏服务器端的开发者，也在试图从PaaS的概念中，学习如何提高游戏开发、运营效率的方法。所以就有了以下的研究。
本文主要的研究对象是Google出品的App Engine，以及Amazone的AWS两个产品。实际上微软、IBM也有类似的PaaS（Azure），由于时间精力原因只是粗粗浏览，并未深入。另外国内如阿里云也有一些近似PaaS的服务，但由于名气不大，也不在这里描述了。
作为一个PaaS，我们可以注意到，主要会分成几个层面来看，能比较准确的把握其特性。否则纷繁的技术名词，各种支持方案，会让人眼花缭乱。这几个层面就是：
- 应用场景：一款PaaS希望解决的重点问题
- 开发支持：PaaS是一种允许用户的代码运行的服务，那么可以运行怎样的代码，怎样方便用户上传自己的代码（或程序），如何管理这些代码，是一个重要的问题。
- 运维管理：PaaS最让人感到方便的，就是几乎都号称“无需用户干预”的自动化运维，不需要用户自己去部署服务器、配置软件等等，但这种能力到底是怎样，也是一个非常重要的部分。
- 关联配套：一个在PaaS上运行的程序，是完成不了太多的任务的，起码需要有一个数据库之类的存储软件。实际上的商业应用中，除了数据库以外，还可能需要大量其他的配套程序，才能让你的业务逻辑程序运行完整，比如Memcache，甚至Crontab这样的程序。由于PaaS号称“帮你运维”一切，所以很多都直接把这些服务也安装部署好给你用，你只要用服务商提供的接入参数，直接使用即可。那么服务商提供怎样的配套服务，有什么能力，是PaaS服务里面一个至关重要的特性，也是各种服务商“争奇斗艳”的主战场。
GAE(Google App Engine)
应用场景
Google自己的Web服务，是具备一整套“基础设施”的，包括Web应用（如PHP）的运行框架、BigTable、GFS等等广为人知的服务器端软件。所以Google App Engine的设计目标，就是让用户可以很方便的使用这一整套“基础设施”。从某种意义上来说，为了使用Google的配套服务，可能会比托管运行自己的Web应用程序，更吸引人。Google的基础设施，一般都是以“分布式”为卖点，提供超大承载量，和高度可用性。如果要自己去重建这一整套体系，对于一般的公司来说都几乎是不可能的。但实际上真正需要用到这么大的承载量，也很可能不是“一般的公司”。不过慕名而来的使用者，在Google的保证下获得信心上的安慰，也是一种重要的价值。
开发支持
Google不愧是以技术著称的公司，其运行容器，支持Python\Java\PHP\Go等等几乎所有主流的编程语言，及这些编程语言在Web应用程序方面的标准框架，如Servlet for Java。看到这里，不禁叹息于，游戏领域并没有什么“应用框架标准”——所以游戏服务器程序的模型真是五花八门无奇不有，这也让游戏服务的提供变得异常繁复困难。
GAE提供的开发工具，可以帮助开发者很方便的测试和部署代码到PaaS上。这些开发工具包括一套结合Eclipse的IDE插件，以及一组命令上传部署工具。用户可以使用这些工具，好像开发测试本地程序一样来使用。当然使用之前还是需要配置自己在GAE上的帐号之类的参数。
GAE另外一个很有特色（也许是缺点）的地方，就是开发者只能在“沙箱”里运行自己的程序，因此你不能用到代码去操作socket、本地文件、线程等等“原生资源”。因为有这样的约束，所以开发者上传的APP可以被认为是“无损”的自动部署到不同的硬件、网络环境上。同时，GAE也提供了大量的配套服务，用来补偿沙箱环境带来的功能缺失。
运维管理
GAE的运维管理从代码部署开始就是全套的。首先是支持从Maven这类代码管理库拉取程序部署，其次是可以部署到Google提供的全球机房，期间提供自动扩容和负载均衡。其中比较值得注意的是，它的运维环境还支持负载灰度和资源配额，也就是可以设置各种参数，来限制缓存空间、实例数、最大线程数、存储空间、使用带宽等等。这些配额并不是简单的基于IaaS的功能继承而来，而是可以针对应用容器，或者各种配套服务为目标来设置。
GAE另外一个很棒的功能是所谓GoogleAnalytics功能。几乎所有云服务商都会带统计功能，但是Google Anlytics因为是针对GAE这种全托管沙箱服务做统计分析的，所以可以获得很多具体的服务统计的细节指标，而不仅仅是操作系统层次的CPU、内存、带宽这种大路货。我们自己部署任何一个服务，对于特定的服务进程，也会想要详尽的统计分析数据，用以监控问题，如果是用GAE，这些服务都是Google提供的，当然统计也是它的应尽职责。
作为一个Web App的容器，GAE在运维配置工具上，提供了全套Web界面的操作软件——Google Cloud Platform Console，可以配置诸如URL、静态资源、MIME类型、根目录、SSL等几乎所有WebServer的配置内容。用了多年的Web Server配置文件终于可以束之高阁了。当然其他的管理服务，也都提供了WEB的配置管理工具。如果你不想手工的去配置这些，也可以使用GAE提供的Restful接口，去用代码操作这些服务配置，这样你可以自己写一个喜欢的管理软件，或者是写个自动化的工具去做这类的配置工作。
关联配套
GAE提供的配套服务，都是那些大名鼎鼎的Google系基础服务，分为两大类型，数十种细类：
存储服务
- App Engine Datastore：NoSQL对象存储服务
- Google Cloud SQL：在GAE上的MySQL，由于是关系数据库，所以不能自动扩容
- Google Cloud Storage：以Restful接口使用的分布式文件系统
辅助服务
- 定时任务：类似crontab这种
- Memcache：最常见的Web后端缓存服务
- Blobstore：一种“数据块”存储服务
- Oauth API：身份鉴权认证服务
- 各种Messaging服务，包括电子邮件、短信、语音等等……
- 全文搜索服务
- 图形处理的API库
- 各种常用的服务器端编程库
从上面来看，最值得关注就是存储类服务，毕竟Google是处理大数据的互联网鼻祖。由于一般的商业互联网服务，都很依赖一个容量大、方便扩容的数据存储层，所以Google这套东西是非常有价值的。可惜作为游戏领域，数据大倒是大，就是其数据关系一般比较简单，就是玩家的存档数据而已，所以游戏开发商如果用这些BigTable、GFS为基础的服务，从延迟性和成本上看，好像都不是特别有必要。
另外从辅助服务来看，细节到连crontab都提供，更不用说各种服务器开发库，只有你想不到，没有他没准备到的。这对于开发者来说是一个很方便的地方，因为一来不需要到处找各种开源库，二来也无需费口舌去和同事统一各种开发库，只需要用GAE的就好了。