相信有很多人对PaaS持谨慎态度，到底是用还是不用?而在前一阶段“ 用户指责Heroku私自修改路由机制造成高支出”这场风暴过境后，PaaS似乎变的更加让人望而却步了。然则PaaS真像这些负面所说，高投入之后却带不来应有的回报?下面就看一看那些来自PaaS的正能量，本文将以一个重点做陈述，下面来一览High Scalability上总结的 小团队PaaS成功之旅：
SongPop
SongPop，音乐版你画我猜游戏;于2012年5月上线，现已拥有6000万个用户，位列2012年iOS游戏下载榜第5。而今SongPop已有能力处理日百万活跃用户的线上活动，然而问题的关键却在于SongPop的工程师团队只有6人!其中也仅有一个人在做全职的后端工作。SongPop只花了不到6个月就实现了从0到1万每秒查询的扩展，他们把大部分的功劳归结于所使用的PaaS平台 —— Goolge App Engine。
经验总结如下：只做轻活，让PaaS去承担重的部分;当你需要扩展时，你只需要购买更多的资源和做少量的调整(当然，也可能会很多);得到的回报是可以专心于App的特色开发，并且能够以很小的团队开始。
SongPop的架构图解：
#p#
单一的看架构图，显然不能知晓SongPop以6人工作团队去支撑每天百万活跃用户的关键。下面来看一下SongPop问题解决策略：
学到的知识
Premier Support(企业技术支持服务)。看起来很像是推销员的宣传曲调?然而一旦活跃用户达到了10万，它们就会开启一个Premier Support账户，这让他们可以与一个在线工程师进行洽谈，解决宕机问题。
Denormalize(反规范化)。为了降低可预见的延迟，它们将几个模型中的数据汇集到一个实体中。一个很老的方法，但是却很实用。
Cache(缓存)。为了减少用户对游戏对手列表的查询，列表会被储存到缓存中，这同样是GAE的特性之一。这个以及反规范化操作将花费一个工程师4天左右的时间。
Deadlines(截止时间)。一旦某个操作的性能衰退到一个临界，是时候转换到一个更可预知的策略。
复合索引。查询变的缓慢，其原因归结于大部分索引性能被占用。解决方案就是使用组合索引或者把数据整合到一个实体中，这个问题的发现来自Premier Support的帮助，同样这也是PaaS的弱点之一。
轻易实现与其它服务的整合。类似Google和Amazon这样的公司都有一个相同的优势，它们一般会建立一整套的协作服务。鉴于SongPop每天需要世界范围类的处理和分配17TB的音乐和图片，Google Cloud Storage显然很适合他们，并且易于在GAE中使用。对于大数据技术，Google BigQuery更是随时就绪。这也是设计中重要的一点。
位置头文件。GAE请求自动的包含了基于客户端请求IP的位置信息，SongPop使用了这个信息去为玩家匹配对手，并构建配置文件。
Synchronous Simulated Gameplay。SongPop使用的一个创新策略就是Synchronous Simulated Gameplay。在游戏中保障可扩展、一致性、低延迟是相当不容易的，那么SongPop是如何做到的呢?SongPop的做法是将游戏记录，然后与你对战(就像你和其它人做的一样)。你将得到一种与玩家对战的游戏体验，但是这样工程师就避免了很多技术挑战。只需要储存声音片段和游戏结果，匹配玩家进行游戏，然后做出响应。确实很聪明。(更多详请移足 “SongPop如何使用Google App Engine和Google Cloud Storage发展到6000万用户”)
通过以上几个关键点，SongPop成功的实现了以6人工程师团队处理每日百万的在线用户。然而从Google App Engine这个PaaS服务获益绝不是SongPop一个，还有Rovio等：
几个从GAE获益的公司：
1. Ravio—— “愤怒小鸟”的拥有者。使用App Engine仅花费2周的工作就推出了游戏的网页版，使他们能够利用机会快速发展它们的业务。
2. GetAround—— TechCrunch Disrupt出品的汽车租赁服务，使用App Engine建立了一个连接汽车业主的市场，用户可以从中租借汽车。几乎无额外工作就完成了他们产品的扩展。
3. MAG Interactive—— 休闲游戏的开发者，热门游戏Ruzzle的创建者;通过App Engine对后端进行扩展，迅速的发展到500万用户，期间更“老练”的未发生任何扩展问题。
4. Nubbius—— Cloud Gate使用App Engine建立，允许律师在任何地点管理其工作流程的SaaS平台。在快速部署扩展的同时，每年成本节约更超过13万美元。
5. RedBus，在线旅行社使用Google BigQuery调度上万汽车的日程表。不到30秒就可以分析2TB的数据(在Hadoop上需要大约一天的时间)，成本却不到Hadoop基础设施的20%。
总结
以上阐述的是一些从Google App Engine中获益的用例，然而从Google App Engine中获利的公司绝不止以上几个;同样可以获益的PaaS平台也绝不是Google一家所有，比如：Netflix大爱的Amazon，受广大微软用户拥护的Azure，以及广受Rails用户喜欢、虽然前一阶段却遭受质疑的Heroku。
由此可见，***的服务是不存在的(毕竟还存在宕机、安全这些难以攻克的问题)，选择匹配自己业务类型(数据类型及程序原型等)的服务才是根本。同样，随着PaaS平台发展的愈加成熟，各个服务的缺点会得到进一步改善，优点则会更加的突出。而经过用户与服务供应商之间的共同努力，从中获益的模式以及途径将变的更加清晰。
