2009年，我发现了谷歌App Engine，并很快爱上了这一服务。这一服务承诺，任何软件开发者都能开发面向任何用户，在任何时间、任何地点都可以使用的应用，同时不必担心服务器配置、数据库设置、操作系统版本、信息安全漏洞、负载平衡，或是规模如何扩大的问题。这意味着，应用将可以自动扩大规模！我们所要做的只是撰写代码，而AppEngine将为我们完成其余一切工作。

　　2009年时我就已经看到，到2015年，很大一部分互联网代码将运行在类似的平台上。谁会想要纠结配置和运营问题？系统管理员将可以从复杂的工作中被解放出来。最终，我们将可以自由编写代码，而不必担心如何去执行，开奖，以及通过什么平台去执行。我们不必再关注规模，并可以从复杂的运营工作中被解放出来。我们的未来一片光明，不必再关注如何配置等细节。

　　然而，事情与我们想象中并不完全一样。

　　为什么会这样？

　　目前的现实并不是“一次开发，在任何地方运行”。AppEngine仍在履行，并将继续履行最初的承诺。（这是我仍在业余项目中使用App Engine的原因。）然而在这一过程中，你会遇到种种问题，例如难以解释的内存泄漏，或是漫长的等待时间。正如一名来自谷歌的朋友所说：“App Engine非常有趣。该服务面向所有用户的运行速度都是同样的缓慢，而无论用户有多少。”

　　市面上还有许多其他平台即服务（PaaS）提供商。例如，云计算市场领先者亚马逊也提供了PaaS产品，即Elastic Beanstalk。我也曾频繁使用Heroku，但这款产品同样非常糟糕。在处理异步任务和自动负载平衡等方面，Heroku不如App Engine，不过在部署和PostgreSQL数据库等方面要好。然而，Heroku并未提供广泛的应用程序接口（API）。通过谷歌，你实际上能获得比其他地方更好的API。这就是你通过谷歌平台去运行代码的优势和劣势。

　　不过目前，谷歌自身也不像2009年时一样重视这一领域。2012年时，由于对App Engine状况的不满，谷歌推出谷歌Compute Engine，即亚马逊AWS服务的直接竞争对手。毫无疑问，直播，相对于采购设备并搭建自己的服务，利用这样的服务将更方便。不过，从易用性、灵活性和部署时间来看，这些服务相对于PaaS服务似乎是一种倒退。那么，为何PaaS服务未能征服所有市场？

　　PaaS服务取得过成功。例如，Snapchat就运行在App Engine之上，可汗学院也是如此。Genius和ProductHunt则基于Heroku。这两大平台也为其他许多创业公司和大公司提供了服务。不过，如果PaaS能取得更大的成功，那么谷歌原本没有必要推出Compute Engine，Docker就不会成为新的热点，而DevOps也不会像现在一样知名。

　　那么，为何仍有许多人放弃PaaS，转而开发自己的AWS和Compute Engine实例？为何App Engine、Heroku和Elastic Beanstalk未能征服世界？良好的控制性是否真的很重要？

　　我猜测，原因包括3个方面：成本、对开发者的锁定，以及文化。

　　App Engine的价格会经常性下调，但这样的调价过于频繁，令人迷惑。单一的实例，即一个简单的虚拟机，成本要超过每天1美元，这还不计算存储或带宽成本。Heroku的情况也是类似。通过购买及运行自己的服务器，你能获得更好的性价比。尽管这时你会遇到更多的麻烦，导致开发时间被延长，但转而使用PaaS带来的好处对许多人来说并没有足够的价值。

　　随后是被锁定的问题。一旦你在App Engine的订制API之上开发了应用，你将需要专注于这一平台。你没有一种较好的方式回退，并转而使用另一家公司的平台。这种对开发者的锁定在其他PaaS服务中并不是很明显，但仍然存在。基础设施即服务（IaaS）领域有着OpenStack和Docker等通用标准，而PaaS领域没有这样的事实标准。

　　第三个原因，也是被认为最重要的一点原因在于文化。企业并不希望放弃对自主系统的控制，即使这样的控制权将导致很严重的复杂性。可以理解，系统管理员不希望丢掉自己的工作。

　　不过，这3点原因都是暂时性的。成本正在持续下降，文化在不断改变。有迹象表明，可互操作的PaaS服务和相应标准正在缓慢发展。（你可以认为，Docker就是这一趋势下的产物。）

　　在电力刚刚出现的时代，所有工厂都使用自己的发电机，但随后都转向了公共的电网。IaaS相当于所有公司都从电网中获得电力，但随后通过自主的变压器将电力转换为自己所需的形式。我认为，PaaS服务仍将继续发展。在这样的世界里，在代码运行过程中，开发者不必了解或关注服务器的问题。这样的趋势只是比我想象中略微缓慢。

　　内容转载自公众号

　　TechCrunch中国