Cloud Foundry vs. OpenShift：看RedHat与Pivotal的策略对决

PaaS（平台即服务）位于IaaS（基础设施即服务）之上，在云计算生态系统中扮演着一个有趣的角色。使用IaaS，你可以拥有主机或虚拟主机，无需担心物理层就按需地使用计算资源，IaaS典型的代表就是 Amazon EC2。PaaS则包括了基础设施、存储、数据库、信息，并将这些资源作为服务提供。我们不妨将PaaS比作远程计算机、磁盘、数据库、信息流及业务处理或者元应用程序的提供者，它们都被封装成“堆栈”或者“沙箱”。SaaS（软件即服务）一般可理解成提供具体业务逻辑的应用程序，比如CMS（内容管理系统）或者CRM（客户关系管理）系统。对比IaaS，PaaS的附加价值在于自动提供所有资源和应用程序，从而节省了大量时间。

时至今日，Red Hat的OpenShift和Pivotal的Cloud Foundry已成为两大主要开源PaaS系统，分别提供了三个版本：托管、企业和开源。本篇文章将着重对比这两个平台的企业版本，它们针对企图内部云或数据中心部署PaaS进行了独到的设计。当然，不管是托管还是企业版本都是基于开源版本开发。

首先，请勿混淆PaaS系统和配置管理及调度工具，比如Puppet、Chef、Ansible、Salt等。当然，不排除使用Puppet建立PaaS或SaaS的情况，或者只是简单做大量服务器的配置管理。OpenShift其实就是使用了Puppet，当然也集成了一些其他工具。Cloud Foundry则使用了另一个配置管理工具：BOSH。

细微的差别

Cloud Foundry和OpenShift功能和PaaS实现方法都非常相似，但是在术语的使用和部署方法略有差别：都提供了一个Linux平台，并使用轻量级容器，让其可以使用不同开源语言及框架去运行应用程序；同时它们都搭载了一些通用的服务，比如数据库。

对于部署应用程序源代码，OpenShift使用了Git，但是同样允许用户部署二进制软件包。Cloud Foundry只允许二进制（暂时只支持.WAR文件，后续肯定会有更多添加），然后自动化将它们与语言buildpacks、框架（比如Java和Tomcat）和服务（比如数据库）整合。 Buildpack格式由Heroku开发并贡献给开源社区，当下已经有大量buildpack被开发，其中大部分为Cloud Foundry使用。

Cloud Foundry原生提供4个标准的buildpack：Java、Node.js、Ruby以及Go。大多数情况下，大部分的开源语言及框架都已有对应的buildpack，你需要做的只是在Cloud Foundry上加载对应的buildpack。如果你所需的技术并不存在对应的buildpack也不用担心，只需要几行Ruby或者其他脚本语言代码就可以建立。

OpenShift并不支持buildpack，取而代之它使用了cartridge，包含了数据库、语言、框架及QuickStarts（提供了大量已配置应用程序代码和库）。

OpenShift cartridge使用插件式设计，因此可以将之整合到独立的应用程序中。OpenShift3个版本自带的cartridge并不相同，但是都提供了非常丰富的选择。这里需要注意的是，Origin（开源版本）中只支持Red Hat Enterprise Linux上存在的组件（或者是Fedora）。

QuickStarts整合了代码与一个以上的cartridges，让整个应用程序的安装变得简单。当OpenShift团队不再维护QucikStarts时，任何愿意对安全问题进行实时更新的技术人员都可以免费建立和发布一个。WordPress、Drupal以及Ghost都在QucikStarts支持范畴。类似Cloud Foundry的buildpack，OpenShfit cartridges和QucikStarts建立起来都没什么难度。

OpenShift使用gears在容器中运行应用程序，Cloud Foundry运行建立和封包应用程序的组件被称为droplets，位于Droplet Execution Agents中。不管是OpenShift还是Cloud Foundry，容器间都是隔离的。同时，对比虚拟机来说，它们都非常轻量。在未来，不管是Cloud Foundry还是Open Shift都将支持Doker容器。

大的特性

Cloud Foundry存在一个杀手级应用，也就是Pivotal的两个Cloud Foundry产品（Pivotal Web Services和Pivotal CF）都支持Pivotal Big Data Suite，其包含了 Pivotal HD（Pivotal的Hadoop发行版）、为Hadoop准备的HAWQ SQL、GemFire XD 分析以及为Apache Hadoop Java提供的Spring框架。

通过Pivotal得知，管理员定义HDFS和MapReduce实例的服务池时，使用Pivotal CF从零开始只需要5分钟。然后开发者或者应用程序就可以从服务池中取出自己想要的，这个过程也只需要2秒钟，同时在后台还可以在资源池中建立一个新的实例。当被请求实例不再需求时，它还可以被释放。

Pivotal还提供了一个Mobile Services Suite，它可以与Pivotal CF和Pivotal HD进行整合，这些得益于2013年价值6500万美元的Xtreme Lab收购。这是Pivotal Paas上一个典型的MBaaS（移动后端即服务），通过集成建立在PaaS上的应用程序实现。

OpenShift的一个特点则是自动化应用程序扩展，在应用程序过载时，系统会自动的添加gears甚至是节点。该功能被OpenShift原生支持，因此并不需要一个前端扩展服务。在新的应用程序建立时，你只需要在一台主机上打勾，然后配置流量触发器来增加或移除gears。

同时，OpenShift会自动识别一个没有任何HTTP流量的应用程序，然后停止闲置的gears，这个过程并不需要任何开发者或运营人员参与。当这个应用程序得到请求后，OpenStack会自动将之加载到内存并处理HTTP请求。在应用产生问题时，OpenShift会自动开始和重启对应程序，这些特性都会降低监视和运营的工作量。

选择一个PaaS

在本地安装OpenShift时非常顺利，期间只发生过一次错误――安装不支持的虚拟机管理器。然而这个操作在Clound Foundry上并不顺利，虽然ActiveState的Stackato版本比Cloud Foundry的开源版本更容易安装。这个体验让我觉得在安装上OpenShift更胜一筹，但是，从另一个角度来说，两个平台的在线版本使用都非常简单。同时，如果企业要在私有云或者自己数据中心安装时必然会聘请一个非常有经验的顾问。

在OpenShift上，空闲gear处理是一个非常大的亮点，这将允许一个非常高的应用程序密度，同时应用程序自动扩展也非常有优势。因为缺少这些特性，Pivotal CF在管理上的得分只能达到8.1，同时我们相信这两个特性是大部分企业喜闻乐见的。需要注意的是，Pivotal CF已经将这两个特性纳入规划图中。

Cloud Foundry（Pivotal CF）最大的优势无疑是支持Pivotal的大数据和移动服务套件，这个特性大幅度的提高了Pivotal CF的得分。在支持上，如果Pivotal CF的得分是9.0，那么OpenShift只能得到可怜的8分。当然也许你并不在意这两个特性，因为这些完全取决于部署的需求。

究竟该选择哪个PaaS，这里受到多个因素影响，IT部门需要认真的进行审核。如果应用程序密度驱动了你们的安装，那么OpenShift是个不错的选择。同样，如果你的开发者是Git重度控，他们也可能更喜欢OpenShift。但是，如果你们需要迎合大数据和移动需求，那么Pivotal CF必将是完美的选择。

Cloud Foundry和OpenShift特性对比

原文链接： PaaS shoot-out: Cloud Foundry vs. OpenShift （翻译/童阳 责编/仲浩)