本节书摘来自华章出版社《PaaS程序设计》一书中的第3章，第3.1节，作者 Lucas Carlson，更多章节内容可以访问云栖社区“华章计算机”公众号查看
3.1 不可移植的PaaS：遵照一个模板
采用不可移植PaaS的平台即服务，我们就可以基于这个平台的独特规范和API编写代码，从而创建应用。
这意味着我们的代码结构需要严格依附于特定的模板或应用编程接口（API）。这些API可能主要集中在服务数据库、存储架构或者搜索架构上。而其他时候，API属于低层次并且面向编码的。有时候我们必须使用专门为那个平台所构建的特定语言。
正如我们所看到的，这种平台里有各种不同类型的“钩子”，使得它可移植性较差。最早形式的平台即服务就是建立在这种结构化很强的想法之上。这些从早期实践中诞生的雏形，逐渐形成了我们现在的平台即服务。
但问题很快就出现了：为什么我们必须基于私有API编写代码呢？难道为了这些优势以及对数据的访问就得失去灵活性？在我们检视新生代公司针对这个问题的回答之前，先看看不可移植PaaS领域里的几个主角。
3.1.1 Force.com
作为Salesforce的开发者平台，诞生于2008年的Force.com（http://force.com），允许开发者扩展Salesforce的功能从而创建应用，而Salesforce（http://www.salesforce.com）则是一个非常流行的SaaS客户关系管理（CRM）销售工具。这是我们知道的PaaS的鼻祖之一。Force.com激发了一代应用，数以千计的开发者开发了新的应用来访问、分析Salesforce丰富的数据。
Force.com的平台即服务提供Web服务的应用编程接口以及工具集、一个用于创建应用的用户接口、一个用于存储数据的数据库以及基础的网站托管功能。最近，平台添加了移动功能，使得基于Force.com的PaaS平台开发移动应用也一样便捷。
使用Force.com的缺点是：开发者不能随意使用编程语言创建通用应用。应用逻辑层建立于Apex之上，它是运行在Force.com上的一种强类型、面向对象、类似于Java的语言。优点是基于Web的接口创建新应用相对简单、便捷。我们可以选择自己想要的数据类型、创建数据结构，可以自动生成Web和移动设备界面并收集数据。
在数据输入选项的基础上，我们也能加入公式、审批程序、发送邮件，并且测试快速、简单。Force.com的PaaS平台有自己的Force.com集成开发环境，开发者们测试、部署应用都很快速、简单。
当我们在Force.com平台的约束下工作时，不需要去考虑扩展、管理应用问题，Salesforce替我们完成了。PaaS正是采用了这些基础理念，才能获得如此的流行度。
随着Force.com平台的成熟，它支持越来越多的服务：例如Database.com（http://database.com），提供定制接口和数据输入，为全世界近100 000商家提供数据库服务。
3.1.2 Google App Engine
Google App Engine（http://developers.google.com/appenqine/），也是2008年发布的，是PaaS最早版本之一。GAE的承诺是：开发者们可以挖掘Google的巨大能力、利用Google运算资源，以及使用Google的设备和运维设备的专家技术。但我们的应用必须遵守Google的标准。Google不仅建立了运维团队，还有一整套工具和系统，以及其特定的工作方式——他们这种工作方式正是为了扩展到“Google规模”。
我们探讨的是什么样的规模呢？在这种规模里，我们需要成千上万台设备来解决一个问题。当我们面对像Google这么大的规模时，工具要非常规范。为了能够处理海量数据，就必须这么做。毫不夸张地说，Google基本上处理了整个互联网的数据。GAE的中心思想之一就是如果遵照它的标准，我们的应用也可以具备这些强大的功能，而且只需要支付使用的那部分功能的费用。
GAE为什么不支持可移植的原因很明显。只有在我们按照Google的一套规则使用时，才能接入它现有的基础设施。一方面，我们得按照Google规定的方式编写代码。另一方面，如果这么做，我们就能获得在Google的规模上运行程序的好处。
很多PaaS平台都会有各种限制。当开发者面对不可移植的PaaS，例如GAE，那些限制是很严格的。开发者必须得尽可能遵从这些规范，才能充分运用GAE的特长。
使用GAE，对于访问文件系统、内存访问、能使用的内存数量以及每个进程能运行的时间都有限制。
这些局限性迫使开发者想其他办法。例如，假设我们有一个网站需要编译很多清单列表，并计算列表上的数据项。在传统主机环境里，当一个用户访问这个网站，传送结果需要相当多的时间。所有过程必须在结果返回给用户前完成。根据处理的复杂度，这一过程很容易，大概需要数秒的时间。
GAE的另一个局限是：我们的应用需要很长时间才能获得结果。如果不能很快返回，GAE就会杀掉这个进程。
如果应用在设计的时候就知道不能运行很长时间，这对用户体验来说其实是开发中的一个积极因素。这迫使开发者问自己：“如果不是简单地按我通常的做法，Google会让我怎么做呢？”因此，可以创建一个缓存，每当用户访问网站时从缓存中取出数据填充到列表中，而不用每次都编译这个列表。缓存能很快响应并提供最佳的用户体验。为了后台编译缓存，我们可能需要用另一套Google工具，以一种可扩展性更强的方式来做运算，然后将结果放到缓存数据库里。
GAE有很好的前景和很大的客户份额。它的承诺——充分运用Google的资源——使得它成为不可移植PaaS领域的典范。
3.1.3 Windows Azure
微软也在努力思考如何创建一个PaaS平台。微软的.NET Framework专家引导公司围绕.NET来思考最佳实现方式。2008年，微软发布了Windows Azure（http://www.windowsazure.com）。
公司着手创建一组库。其设计考虑是：如果开发者将这些库包含在他们的系统中， Azure就可以利用这些库来扩展系统。微软也提供可扩展的标准服务。
有了Windows Azure，我们就拥有了一些基础系统，例如消息总线和队列系统，以及一组满足应用不同需求的选项。这些为开发者提供了一些模式，以支持他们创建基于互联网互通的分布式应用。如果我们融入了微软提供的库、技术和服务，就可以利用Azure系统简单而快速地扩展应用。
最近，微软开始脱离不可移植Azure系统，去除一些将开发者捆绑到特定服务上的需求。允许扩展到不同语言和技术，从而将Azure慢慢转型到可移植领域，这就不需要为了适应平台而调整代码。因此，Azure从不可移植起步，现在正慢慢转型到可移植。事实上，微软最近发布了一个可移植版本的平台即服务。
3.1.4 不可移植PaaS总结
尽管所有这些PaaS选项开始是不可移植的，很多平台都开始添加功能使得自己越来越可移植。GAE发布了PHP支持服务，需要做的修改越来越少。Windows Azure也发布了PHP支持服务，而且开发者可以做得更多，而不用像以前那样依附于微软的接口。
