2011年12月，我在谷歌工作了9年，领导着一个由10名软件开发人员组成的团队，支持AdSense业务。我们的产品组合由30多个软件系统组成，其中大部分是过去十年中构建的用于商业智能的web应用程序，每一个都在一个堆栈上，这在当时似乎是个好主意。有些是最先进的定制服务器，建立在（当时）最新的googleweb服务器库上，直接运行在Borg上。有些是托管托管服务上的一个LAMP堆栈。有些是在某人的工作站上作为cron作业运行的。有些是怪异的怪物，比如运行在Borg上的LAMP stack，Apache定制用于生产负载均衡器和加密。事情每天都在以新的奇妙的方式发生着。这是我们所能做的一切，以保持系统运行-只是勉强。产品经理和工程师们很沮丧。一个典型的对话是这样的：

下午："你以为添加foobar功能很容易，但已经四天了！"Eng："我知道，我知道，但是我必须先升级包管理器版本，然后迁移掉一些不推荐使用的API。我几乎把这些东西都做完了。我也很想从foobar开始。"PM："好吧，现在，这太令人失望了。"

我调查了整个团队，找出了我们效率低下的根本原因：我们把60%的时间花在了维护上。我问多少时间合适，答案是勉强的25%。我们的目标是将维护时间减少到这一点，这将节省相当于10名开发者中3.5人的时间。一位朋友很热情地推荐了它——他曾在一个个人网站上使用过它——他赞不绝口地说，它维护率低，自动伸缩，而且内置了谷歌云数据存储和用户管理等功能。另一个朋友亚历克斯·马尔泰利（Alex Martelli）正在用它做几个个人项目。我自己从2010年起就把它用于慈善网站。我们决定把它用于我们所有的网络服务。这是团队进入PaaS的第一步。

大约在同一时间，我们开始使用Dremel，Google内部版本的BigQuery。与MapReduce相比，它的速度非常快，而且它的伸缩性也差不多。我们决定重新编写所有的数据处理来使用它，尽管当时它和appengine之间还有一些功能上的差距，例如可视化和数据管道。我们推出的解决方案仍被谷歌的数百个项目使用。现在，谷歌云平台用户可以使用谷歌云数据实验室访问类似的功能。是的，我们必须重写30个系统，但它们无论如何都需要重写。完成后，在云上开发的速度大大加快了——我记得看到appengine日志时非常惊讶，我在一个编码会话中完成了100个代码、测试和部署周期。一旦事情成功了，他们就继续工作了很长一段时间。我们停止了为下一个项目选择什么堆栈的争论。我们刚刚从Google云平台抓到了最明显的一个，并开始构建。如果我们在云基础设施中发现一个bug，它会被专家及时修复。花几个小时来解决库兼容性问题，这是多么大的变化啊！

最棒的是，我们很快把维修时间降到了25%，而且一直在下降。两年后我重复了这个调查；团队报告说他们现在只花了5%的时间在维护上。

我们开始有好的和不同的问题。这家公司的想法产生速度不够快，我们忙不过来，也没有积压的工作。我们开始在每个季度末花两个星期的时间进行"黑客竞速"，看看我们能想出什么。我们将一半的开发人员转移到云计算之外的另一个更繁忙的团队。我们处理了更大的项目，并开始与更大的开发团队合作。

在看到使用PaaS如何改变了我的团队之后，我希望每个人都能体验一下。谢天谢地，这些技术不仅适用于谷歌的工程师，也适用于全世界的开发者。这是自1999年我第一次访问谷歌搜索以来我见过的最具变革性的技术——它让开发者不再做傻事，而是继续开发为我们的生活增值的应用程序。