paas-openshift

https://www.openshift.com/pricing/index.html
OpenShift是红帽的云开发平台即服务（PaaS）。自由和开放源码的云计算平台使开发人员能够创建、测试和运行他们的应用程序，并且可以把它们部署到云中。
https://www.cloudfoundry.org/
Cloud Foundry是VMware推出的业界第一个开源PaaS云平台，它支持多种框架、语言、运行时环境、云平台及应用服务，使开发人员能够在几秒钟内进行应用程序的部署和扩展，无需担心任何基础架构的问题。

对PaaS的简单介绍

问题描述。

一般我们传统开发，折腾服务器在所难免。选择时得考虑CPU大小, 内存多少，带宽如何，以及有什么操作系统; 然后还得在上面安装自己需要的语言、框架、服务，Web 服务器(虽然这一般都有默认安装)，应用服务器，以及其它中间件之类的；再有就是登录上去然后发布、管理应用，维护应用和服务器本身。

如果只有少量应用或服务器，而且应用更新也不是很频繁；或者我们有专门的服务器管理员/运维人员(用专业的部署管理工具)，我们在服务器上折腾也没什么。

但一旦场景复杂起来，比如虚拟机/应用很多，或者应用本身更新比较频繁，重复操作就会增多，我们的人力成本就自然而然的提高。

一种解决方案。

在追求“简洁、快速，自动化”的今天，选择PaaS不失为一个很好的选择。PaaS是Platform-as-a-Service的缩写，意思是平台即服务。从最终开发者(用户)的角度来说，就是“把服务器交出来”；而从供应商的角度，就是“把平台交出来“。大多数用户需要在服务器上运行的操作，供应商都以服务的形式提供出来。

也就是说所有与服务器相关的操作，基本上用户都不必关心，PaaS平台都已经帮我们想好了。平台提供的运行时、服务中间件、开发工具等一般都能满足我们的要求，用户只专心编写与应用直接相关的应用代码就行了。不用担心负载均衡、缓存、扩展，把系统管理和运维忘了吧！

----------------------------------------------------------------------

当然了，任何事都有利有弊，使用PaaS需要一定成本。举几个例子：

1. 你需要熟悉你所使用的PaaS平台。即使你永远不会对其进行二次开发，但也不能对其完全不了解，至少每个PaaS平台所提供的开发工具你是要学会的。毕竟PaaS平台改变了用户的编程习惯，而改变习惯有时成本是很高的。

2. 一定程度信任你所使用的PaaS平台。代码、数据、应用安全怎样，应用规模比较大时性能能否满足要求，平台是否够稳定，这都需要你自己体验之后才能知道。再就是：你能否容忍将你的代码托管在第三方，公司防火墙外？

3. 被绑定的危险。出于安全等因素，并不是所有PaaS平台所提供的运行时、服务中间件等都是标准的，而是经过修改的。即使不考虑这一点，对于应用开发中常用的功能，大多数PaaS平台都喜欢以扩展服务的方式提供给开发者选择，而这些扩展服务往往会导致PaaS平台的专有性，移植起来不容易。无论是应用的迁入、迁出，还是更改另一PaaS供应商，你都免不了要更改代码。

4. 另外就是没有办法安装系统软件。例如Imagemagick等一些常用的包，平台提供你就能采用。但是如果你另外还需要些什么，你将不得不对其进行破解，或者委曲求全。

5. 不成熟。

对于用户来说，服务器不可见，提供方便的同时也带来了限制。按照供应商服提供的平台“规范”来做，你确实可以减少很多繁琐、重复的工作，但一旦你想按自己的特定需求、不按“规矩”办事，那无疑你会遇到很大的阻力，毕竟服务器对你来说不可见了，你不能在上面进行任何操作。

对OpenShift简单介绍

Openshift.com 是红帽线上的PaaS平台。OpenShift允许个人开发者或开发团队在此平台上创建、测试、部署以及运行应用。

从代码上，OpenShift 平台主要涉及五个项目:

* rhc 访问基于 OpenShift 的 PaaS平台的命令工具。

* origin-server 最核心的项目，包括了 Broker, Node 和各种不同功能的插件(比如：DNS, 通信，验证)。它还包含了一些不可或缺的 cartridges, 在部署OpenShift时会自动安装。

* origin-community-cartridges 社区开发的 cartridges。

* origin-dev-tools在本地或 EC2 上部署OpenShift所需的打包&测试工具。

* puppet-openshift_origin 配置 OpenShift平台的 puppet 脚本。