本文讲的是PaaS发展缓慢的原因究竟是什么，【编者的话】作者是Google App Engine的早期用户，对IaaS、PaaS的发展一直保持关注，作者分析了PaaS平台发展缓慢的原因，主要包括成本、lock-in以及用户习惯几个因素，但是作者认为这些都是暂时的，一个大规模PaaS的时代正在到来。
在2009年，我发现了Google App引擎，从那以后就喜欢上了它。它预期目标是：让任何软件开发者都可以构建出任何人在任何地方，7天24小时都能使用的web服务。开发者再也不必担心服务配置、或者数据库的启动、操作系统的版本、安全补丁，或者负载均衡等等方面的要求。应用可以被自动扩展！用户全部需要做的仅仅是完成代码，其他的全部事情都交由App Engine来负责。
在2009年，这一切对我来说多少有些难以置信，到了2015年，大部分的代码已经可以运行在这样类似的平台上。事实上，没有人希望把时间都花费在基础配置和运维工作上。这些平台把系统管理员从繁重的工作束缚中解放出来（我的意思是说，传统的系统管理员或者被解雇，或者被平台提供商雇佣，转型成为开发者）。最后理想的状态是，我们可以自由的书写我们的代码而不必担心这些代码是如何被执行以及在哪里被执行。开发者将从运维工具链中解放，不用再关心应用的自动伸缩，只需要关心代码的具体实现细节即可。
是的，然而到目前为止，在实际生产中，并非能完全按照上面所描述的样子进行。
原因是什么？
当前的产品还远远没有实现“一次写入，到处运行”的功能，App Engine实际上已经在实现，并且还要继续实现它最初的目标。（这也是我为何仍然使用App Engine来制作幻灯片的原因）。目前，在用户看来，它可能是一系列难懂的指令，以及偶然的令人费解的内存泄露以及等待时间。就像一个谷歌员工所说：“虽然App Engine 的功能十分令人惊讶，不论有多少用户在使用，它们运行速度都是一样慢。”
目前有许多其它的PaaS竞争者。即使是AWS，被誉为底层基础设置虚拟计算方面的无冕之王，也开始通过Elastic Beanstalk来提供PaaS服务。我经常使用Heroku提供的专业的服务，它确实有许多做得很好的地方：在处理异步任务或者自动负载均衡方面，并非像App Engine做的一样好，但是在git-push-to-deploy，以及PostgreSQL数据库方面做的要更好。但是它没有提供大量可用的API，因此使用场景上受到了限制。Google的API就比较完善，通过这些API你几乎可以再任何场景下使用相应的服务。在Google的平台上运行你的代码（或多或少），有好处也有坏处，这是你需要去权衡的。现在看来，即使是Google自身也看起来并没有执着于它们在2009年所提出的概念。在2012年，大概不满足于App Engine所取得的成功，它们启动了新的项目即Google Compute Engine，这个项目逐渐成为了Amazon Web Services的直接的竞争对手。当然，它们两家在除了基本的服务提供外，还为用户提供了许多其他的便利。然而，在同样提供PaaS服务的同行看来，但是就易用性、灵活性以及开发时间而言，它们两家看起来似乎都有不同程度的倒退。为什么我感到有些不对劲？为什么PaaS还发展得如此缓慢？
虽然PaaS领域已经取得了一些成功，著名的Snapchat，可以运行在App Engine之上，正如Khan Academy所做的，Genius以及Product Hunt都可以在Heroku上运行。有许多创业公司和相对成熟一点的公司都在使用它们所提供的服务。但是如果PaaS平台能够更加成功，Google将不会为Compute Engine而如此操心。如果PaaS平台可以更加成功，Docker将不会像现在这样受欢迎，如果PaaS更加成功，DevOps也不会像现在这样被如此被重视。
为何人们仍然热衷于使用AWS以及Compute Engine？为何App Engine以及Heroku以及Elastic Beanstalk没有完全占领市场？更细粒度的资源控制真的是如此重要吗？
我认为原因来自于以下三个方面：成本、lock-in、以及用户习惯。
App Engine的价格在不断下降，但是价格仍然比较昂贵并且价格的制定也让人很疑惑。举一个例子：租用一个小型的虚拟机，一天需要花费超过一美元，这还不包括存储和带宽的支出。使用Heroku也基本上是相同的价格。虽然这样可以为用户提供很多好处，如果用户自己购买服务器，可能会有很多麻烦的运维操作，很大程度上减少了开发的时间。但我认为目前服务的价格仍然比较昂贵。
还有一个方面是lock-in，一旦用户在App Engine所提供的API的基础上构建好了自己的服务，就相当于作出了承诺，如果用户想进行back away操作或者希望转换到其它服务平台上，就会变得很困难。对于其它PaaS提供商，lock-in的现象可能少一点，但仍然是存在的。目前仍然没有一个通用的PaaS标准，例如像IaaS层上的OpenStack和Docker这样的标准。
第三方面，看起来最容易被忽视，也可能是最重要的一个因素，就是用户习惯。作为公司来说，通常并不希望放弃对它们自己的系统的控制权。即使这种控制会使得公司花费很多精力，并且可以理解的是，作为系统管理员，也并不想把他们自己排除在系统管理的工作之外。
在我看来，所有的关于这三个方面的原因是导致PaaS暂时发展缓慢的原因，但是我认为这些都是暂时的。成本会持续下降，用户习惯会逐渐发生改变，并且目前已经有一些信号预示着稳定、标准化的PaaS服务即将到来。（你可能会认为Docker在这个方面正在大步前进）
在电器化时代的早期，各个工厂都有他们自己的发电机。然而最终，它们都采用了统一的电网来提供电力。IaaS服务的理念就类似于每个公司从电网上获得电力供应。但是使用起来仍然很困难，比如对于公司来说，需要把电网上提供的三相交流电转化成单相电，才能使用。对于IaaS平台的使用也一样，公司内部需要在原有服务的基础上进行进一步的定制。我认为我们目前正在向一个大规模的PaaS时代前进，开发者只需要编写可以运行的代码即可，并不需要去知道或者关心有问题的服务器，目前这些正在发生，但可能比我设想的要慢了一些。
原文链接：Whatever Happened To PaaS? （翻译：王哲 校对：李颖杰）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
译者介绍
王哲，浙江大学SEL实验室硕士研究生，目前在云平台团队从事科研和开发工作。浙大团队对PaaS，Docker，大数据和主流开源云计算技术有深入的研究和二次开发经验，团队现联合社区将部分技术文章贡献出来，希望能对读者有所帮助。
原文发布时间为：2015-04-19
本文作者：hessen
本文来自合作伙伴DockerOne，了解相关信息可以关注DockerOne。
原文标题：PaaS发展缓慢的原因究竟是什么？