本节书摘来自华章出版社《PaaS程序设计》一书中的第3章，第3.2节，作者 Lucas Carlson，更多章节内容可以访问云栖社区“华章计算机”公众号查看
3.2 可移植性：不再繁琐
可移植PaaS是这样一种平台，在其上运行的代码编写完成之后，就不需要进行较大修改。开发者在共享主机或者专用主机上开发的代码迁移到可移植PaaS上不再那么困难。想要运行应用不再需要依赖服务转接器。
平台仍然存在局限性，这是需要应对的挑战，但这些局限相对代码来说更偏功能性。
可移植性扩大了平台即服务支持的语言数量和类型，也扩大了语言自身的灵活性。如果我们想要将应用移植到不同的可移植PaaS平台上，需要调整应用的某些内容，但不需要彻底改写系统。
相对而言，看看早期的Google App Engine，那时候只支持Python。我们需要运用某些功能编写特定版本的Python。这给了我们很大的限制：例如，我们不能运行Python最流行框架，Django。 现在的可移植平台即服务上不会再遇到这种问题。
3.2.1 Heroku
Heroku（https://www.heroku.com），创建于2007年，是最早支持可移植平台即服务的公司之一。Heroku看到Force.com和Google App Engine的发展，总结出对于开发者们来说，可以编写任何代码要比必须基于平台的接口编码更有意义。
Heroku公司起步的时候，只支持Ruby的平台独立性，即Ruby编码能以任何形式部署。后来被Salesforce.com公司所收购，并且扩大了语言支持。但Heroku仍然不支持用户访问文件系统。这样就可以更为简单的为用户应用创建多个实例 (Heroku称之为dynos)。如果我们要上传或修改一段代码，最终只需要运行一个实例，如果我们的应用运行需要100个实例，由于上传的文件不能传播，就会导致不一致的实例。为了避免这个问题，Heroku的措施就是开发者不能写入文件系统（除了短期的临时目录）。
对于Google的App Engine，每个应用也有一定的生存期（Heroku会更常见一些）。但也有些后台运行的任务，完成一些异步的工作。这些想法是由Heroku提出的，并设定了可移植平台即服务的早期标准。
Heroku和Google App Engine的进一步比较，例证了可移植PaaS和不可移植PaaS之间的主要区别。
对于Google的App Engine，开发者编写代码要严谨，严格调用Google的API。对于Heroku，开发者的编码——不管它是运行在共享还是独有的主机上——都可移植到Heroku上。可移植性的区别是：要基于供应商的系统编写代码，还是可以用更通用的方式编写代码。之所以可移植是因为同样的代码可以从Heroku迁移到我们自己的系统上，不需要做大修改。
Heroku的另一个创新是关于代码部署。早期的PaaS产品，例如Google的App Engine，在部署代码时都存在问题。Heroku采用了更通用的方式，创建了基于git的系统（git是一个源代码管理工具，支持用户可以追踪自己的软件代码的版本，就像CVS和其他代码管理工具）。
对于Heroku，当我们将代码提交到git源代码管理工具上，将代码推送到Heroku就会触发部署。对开发者来说部署代码非常快速和简单，不像一般使用FTP触发壳托管系统。使用FTP，用户必须查找变更的文件，并确认自己上传和同步的文件。Git可以持续追踪文件变化并且留存历史记录，这样用户不需要自己查找变化的文件。Git工具识别并将这些文件自动同步到平台。
3.2.2 Cloud Foundry
Cloud Foundry（http://www.cloudfoundry.com）由Vmware创建，是支持PaaS的新一代技术。相对于Google App Engine或者Heroku而言，它具有一定的创新，由一组程序和服务组成，可以运行在用户自己的平台即服务上。它遵循开源许可（Apache 2），甚至可以运行在笔记本电脑上。
采用Cloud Foundry，我们可以访问一组程序包和程序，提供与PaaS一样的交互和部署代码体验。它可以管理代码并且可以按用户在PaaS平台上习惯的方式扩展或缩减。
由于Cloud Foundry是开源程序，因此与Heroku、Google App Engine和Windows Azure有着很大的差别。那些都属于托管服务：用户不能查看源代码，也不能修改服务。本质上说，那些是用户无法讨价还价的境况，用户将代码装入黑盒子由系统部署。
Cloud Foundry具备PaaS平台的很多特征，但不是托管式服务。如同Apache一样，用户必须自己运行的技术。然而，它是一个灵活的分布式系统并且比Apache这样的系统要更复杂一些。
它不支持公开注册。如果用户想要注册，必须去找Cloud Foundry的供应商。他们的数量正在增加：AppFog是一个，Vmware提供的托管服务也可以尝试。
与Heroku不同的是，Cloud Foundry创建了REST API，用以取代git部署机制，这是一个新的部署应用的方式。它使用基于Ruby的命令行工具去部署代码。由于REST API，用户可以灵活选择是否集成git、CVS、 Subversion、Darcs、Mercurial、Team Foundation或者其他。如果用户想要不同版本的代码控制，它不会加以规定，而是由用户自己选择。
Cloud Foundry还在如何支持第三方服务方面做出了一些创新的决定。采用Heroku和其他平台即服务技术，用户最快获益的就是他们提供的服务、绑定应用的能力。通常，通过设置环境变量并在应用运行时传递给它。应用读到参数获取数据库的认证。Cloud Foundry提供的机制很相似，但它将这个服务封装——例如MySQL、Postgres以及 Redis——成一个抽象概念，我们可以绑定服务也可以从应用上取消服务。它保留一组环境变量可用，这样我们可以程式化循环使用。
Cloud Foundry也支持用户为多个应用绑定一个数据源，这使得我们调试应用、判断它的状态变得更为简单——不管是产品数据还是审计系统。我们可以将数据源同时绑定到多个不同应用上。
Heroku的创新之一集中在第三方插件市场。通过这个市场，Heroku可以提供其他云工具，使用环境变量，并将工具的认证信息传递给我们的应用。有些PaaS平台，例如AppFog，融入了相似的理念，但是Cloud Foundry目前没有内置与第三方工具整合的功能。
绑定服务是可移植PaaS平台中特有的特征之一，这需要不同编码。当用户尝试将应用迁移到另一个PaaS平台时，一般来说不同部分是关于连接数据库或者数据源的。也经常有不同的需要重写的代码——通常只有很少一部分。
3.2.3 AppFog
CloudFoundry.org（http://cloudfoundry.org）提供的开源工具集是每个开发者都会用的，这推广了平台即服务的应用范围。因为它不属于管理型平台即服务它也融入了新领域。对于开发者来说这意味着在用户使用Cloud Foundry之前，他需要自己安装并运行。如果我们想要在产品环境下使用，需要自己在产品环境下安装并运行，这提供了很大的灵活度，但却削弱了PaaS与生俱来的简单性。
AppFog（http://www.appfog.com）属于管理型和维护型PaaS平台，它采用Cloud Foundry的技术。AppFog开始是一个独立的公司，2013年被CenturyLink收购。
Heroku的另一个创新是它完全基于亚马逊Web Services，直到今天它一直运行在AWS上。这与其他早期的PaaS供应商例如Force.com、Google App Engine以及Azure有很大的不同。那些都创建在自己的平台及基础设施上。Cloud Foundry有两个部分：称为CloudFoundry.org的开源库，以及称为CloudFoundry.com的专享托管平台，这个平台使用CloudFoundry.org编码。
AppFog公司也使用CloudFoundry.org编码，并且在多个基础设施和公共云系统上运行。因此，如果它在亚马逊Web Services运行，也能与OpenStack平台兼容，例如Rackspace、HP Cloud以及其他公司。它甚至可以在OpenStack和vSphere的私有云实例上运行。
从开发者角度，我们会发现AppFog拥有很多CloudFoundry.org所具有的拿来即用的特征。但它运行在很多基础设施之上，为用户提供基础设施的选择和可移植性，就像编码一样。此外，AppFog也采纳了其他平台的一些想法，例如集成第三方云服务，并整合到自己的平台中。结果是:用户登录并在任何自己想要的云设备上运行应用，采用自己运行的技术，为用户提供了在其他系统（例如Heroku）上需要通过第三方插件才能获得的好处。
3.2.4 dotCloud
有些平台更关注PaaS平台后的基础设施，而较少关注用户体验。dotCloud（http://www.dotcloud.com）是第一个创新支持多种语言和技术的平台之一，它通过一个称为Docker（http://github.com/dotcloud/docker）的开源项目推动了Linux容器的流行。
当dotCloud发布时，Heroku只关注Ruby，Google App Engine只支持Python,而Azure只支持.NET。dotCloud则同时支持Python、Java、Ruby以及其他技术。
这个流行的PaaS平台致力于创建支持命令行的系统，与Cloud Foundry相似。它支持Unix命令行和命令的API接口，从而支持用多种语言部署应用。
Cloud Foundry和dotCloud的区别在于如何支持语言。对于Cloud Foundry，整个系统是一个开源工具，这意味着用户可以登录并改变应用运行和管理的方式。管理工作与Cloud Foundry工具集密切相关。dotCloud对应用运行的方法进行抽象，用户部署应用时，可以管理应用运行的方式，保证其符合规范。
3.2.5 CloudBees
CloudBees（http://www.cloudbees.com）是一款特别关注于Java的PaaS平台。它基于Java工具集创建，并包含了Java平台的上使用的通用工具。
CloudBees区别于其他平台的特征是：它集成了持续集成工具，例如Jenkin。事实上，CloudBees雇佣专人维护Jenkin，它已经成为持续集成领域的领导者。这给予了PaaS新转折点，因为它支持系统并扩展了PaaS的应用范围。对于其他平台，其想法是让用户将代码部署到它们的产品上。CloudBees嵌入更多开发工具来扩大其适用范围。
不同于简单地将代码部署到产品上，CloudBees提供一套系统给用户持续性地测试代码，在代码部署到产品之前确认它没问题。用户部署代码之前，CloudBees提供一条更长的途径并增强一些功能帮助用户适应它的平台。迄今为止，CloudBees仍然只支持Java以及支持Java的应用。所以，尽管它扩大了PaaS平台的可用范围，CloudBees仍然只局限于一种技术。
3.2.6 总结：何去何从
对于可移植平台即服务，主要优势是用户可以轻松将现有代码部署到平台上，不用太大修改。这个迭代更快。如果用户想要将应用从某一特定系统迁移到别的环境，可移植平台可以将影响降到最低。
不可移植平台的优势是与平台的功能高耦合。例如，Google App Engine，其优势是能借助于Google的基础设施和维护。对于Windows Azure，其优势是能借助于微软的维护。
如何权衡，关键在于用户想要运行哪种应用。例如，如果我们想要运行Node.js应用，就不能选择Google App Engine。但如果想要使用Google的桌面功能，就不会想要采用Heroku或者AppFog。选择可移植还是不可移植PaaS取决于用户的需求以及想要利用的特征集。然而，当所有都确定了，开发者就需要在应用的路上坚持自己的想法。最后，开发者应当问问自己，代码将来变化的幅度以及应用想要生存的地方。
3.2.7 处理好遗留应用和新应用
用户权衡PaaS选项时的另一个重要考虑是：是迁移现有应用还是创建新的应用？在回答这个问题时，平台及服务是可移植的还是不可移植的就变得尤为重要。
如果代码已经完成，代码迁移到不可移植PaaS平台上将变得更加困难。重构一个复杂的Python应用使得它能在Google App Engine运行，相对于运行在AppFog或Cloud Foundry上要难很多。在Cloud Foundry上，不需要费什么力气就可以正常运行。而在Google App Engine上，它可能需要众多工程资源。
如果是创建新应用，即从头开始并且对于语言和技术选择很灵活，那么用户在选择平台时更具灵活性。如果用户评估技术时侧重于可扩展性和性能，考虑Google App Engine和Windows Azure会更有收获。如果运用Google的运维和基础设施会对开发者的新应用更有帮助，那么应该尝试Google App Engine。需要注意的是：应当提前思考并确认所选择的平台可能会出现的重大问题，并及时应对，不要将自己困住。
另一个因素就是价格。如果开发者使用的不可移植平台价格出现变化，突然贵出很多，将我们的应用迁移的其他供应商那会比采用可移植服务困难很多。
还有一个问题：宕机时间。几乎每个PaaS平台在某个时间都会出现可靠性问题。如果我们的应用只能在某一个平台上运行，当某个时刻平台宕机时我们就是在冒险。如果我们的应用创建得比较健壮能在很多种可移植平台上运行，当平台出现可靠性问题时我们就能体会到其中的好处了。
3.2.8 运用服务
早前，我们在Heroku和Cloud Foundry内容里简单讨论了服务。采用PaaS平台的最大好处之一就是能很快很简单地绑定平台服务，例如MySQL、memcached以及PostgreSQL。还有很多关联好处：有了服务，用户就可以快速启动，服务完成了管理和维护工作，而且通常平台会做好备份并提供冗余。
缺点同样也有。对有些平台，访问数据很困难并且很难查看运行中的服务状态。而有些服务，特别是那些SQL家族的，以扩展性较差著称。当应用壮大时，最大的问题之一是确保掌握自己数据库系统的情况。用户想要能监控代码与数据库交互的所有细节，从而优化自己的数据库。
这是一个权衡的过程。一方面，用户体验不到控制的感觉。而另一方面却有很大的优势：即自动化管理。
当服务以邮件形式出现，服务模板是一个重要的角色。由于邮件服务提供商越来越擅长发送垃圾邮件，所以发送邮件的功能会非常难。云供应商发送邮件时他们习惯性阻止。这就会有个问题，因为垃圾邮件发送者们会借用云上的很多服务器发送大量的邮件。因此，很多云供应商都在黑名单之列。即使用户想发送，但发送邮件不被允许，当用户创建发送邮件的应用时会出现大问题。很幸运，将邮件系统整合到服务模板里可以让用户快速绑定到邮件发送服务器上，帮用户解决了这些问题，Gmail、Hotmail和很多垃圾邮件过滤器的消息都能通过。开发者自己完成这项工作很困难。当我们创建应用时，能够轻松地掌握借助白名单里的托管供应商搭建邮件服务是服务模板很大的优势。
