欢迎来到 PaaS 未来世界

阅读数:5724 2012 年 7 月 20 日 00:00

PaaS 的未来会是什么样的呢?NoOps 和 DevOps 又如何融入其中呢?

PaaS 将会让开发者生活的更加轻松。

实际上,PaaS 是一些事物的混合体,它关注更快的部署用时、更低的准入门槛、更高的扩展性、高可用性和地理上分散的系统等。

那么,如何为 PaaS 做好准备呢?首先,需要理解一些关键概念,而我们首先就会介绍这些概念。

I 本文将会深入介绍 NoOps 和 DevOps 以及它们和 Paas 之间的关系。然后会简短的描述导致 PaaS 技术产生的原因,同时会介绍第一个开源的解决方案 Cloud Foundry。我们会深入介绍它产生的原因、架构以及一个应用的简单部署。本文还将会介绍 PaaS 的核心概念。

NoOps 和 DevOps

首先,我们快速给它们下一个定义:

  • NoOps - 除了部署基于 PaaS 的应用(通常是一个 SaaS 应用)之外,不需要任何运维。这是具有独立开发和产品团队的小型、初创以及中大型企业的主要需求,它们需要能快速地部署原型或应用而不必为基础设施及其他系统相关的问题而操心。
  • DevOps - 开发者和运维人员的结合,形成满足双方需要的职业形象。DevOps 通常维护网络、基础设施、平台及实际的代码库和应用部署。DevOps 很少见、高度集中而且内涵丰富。

在 NoOps 成为开发者的选择之前,DevOps 试图通过为开发者提供运维接口来解决问题。NoOps 的前提是开发者在无需操心运维的情况下即可完成工作。这并不意味着运维的消失。幕后的运维人员会微调一切,保持它的运行。这是他们所擅长的,他们也不会消失。我们仅需确保开发者为了完成工作需要“无需运维”。

开发者不必关心网络,因为没有必要;他们不必处理路由问题、保持实例在线、崩溃或者如何存储,因为他们不需要。他们唯一的责任和工作就是要关注应用及其业务价值。

源自何处?传统开发

传统开发通常包含很多乏味的任务,包括机器配置、资源分配、机器的规格、说明以及相关的沟通,有的还需要预估未来的负载,并预留相应的资金来采购机器。然后是安装、配置、将机器资源放置在数据中心、主机托管中心或者在某些情况下放在公司大楼里。即使在最好的情况下,这些方法都是有挑战的,而在最坏的情况下,则需要经过尝试和错误的考验。PaaS 和未来的 NoOps,甚至某种程度的 DevOps 都消除了这种传统软件开发的噩梦。

所有这些传统的环境问题多年来耗费了软件产业数十亿美元。但是,变革正在发生,并且已经改变了软件开发的模式。这种进步就像从汇编到 C/C++ 再到更高层次的 Java、C#或 Ruby 等抽象语言的进步一样巨大。移植到 PaaS,相应地消除了操作系统的障碍,极大地改善了软件开发方式。

PaaS 和核心原则

PaaS 的核心原则就是简化应用的生命周期管理,即应用的启动、停止和部署。

让我们对传统的部署过程和 PaaS 做一个比较。首先,深入了解一下传统的开发过程。

  1. 获取应用运行需要的机器或实例
  2. 加载操作系统
  3. 设置网络并做好将它放到目标环境的准备
  4. 设置托管的 Web 服务器或准备部署的服务文件及文件夹
  5. 从系统本身独立自主地构建 / 设置应用,推荐在开发机上进行
  6. 验证部署配置能够迁移到不同的环境
  7. 将代码块和应用依赖性加入源代码控制系统
  8. 在某些方式下,从源代码控制系统中获取应用,部署到之前创建的服务器,方法有 move、x-copy、使用 msi 安装、bash 脚本或者配置。

好了,一共需要八步。其中有些步骤很耗时,也很痛苦。接下来我们看看将同样的应用部署到 Paas 解决方案(在这里我们使用 AppFog)中必须要做哪些事情?

  1. 把想要使用的域名告诉 PaaS
  2. 将代码块和应用依赖性加入源代码控制 Github 一直都是一个好地方。
  3. 点击 Create 按钮或者使用简单的命令行工具,如 af push,让代码上线(如图所示)

 然后代码库会自动被推到 PaaS 提供商,自动地构建并部署到系统中。

这就是整个过程。只有三步,很简单。

(点击放大图片)

此屏幕截图是一个非常好的例子,它包含了通过 UI 或者命令行开始所需要的所有内容。这是一个 AppFog PaaS 的预展,其核心利用了 Cloud Foundry。

架构元素——客户端和插件

客户端和插件提供了 UI 和命令行能力,能够通过简单地将应用部署到 PaaS。客户端命令行只有几步。例如:

sudo gem install vmc
vmc target api.cloudfoundry.com

现在,以创建了一个 node.js 应用为例,添加一个包含以下内容的 app.js 文件:

var vmc_port = (process.env.VMC_APP_PORT || 3000);
var vmc_host = (process.env.VCAP_APP_HOST || 'localhost');
var vmc_http = require('http');

http.createServer(function (req, res) {

res.writeHead(200, {'Content-Type': 'text/plain'});

res.end('Foo, I'm Alive!!\n');

}).listen(port, host);

然后在该文件所在的目录下使用如下命令:

vmc push

你会看到一些反馈以及一些单击回车就能继续下一步的问题。初始部署时使 ga 用默认值就可以。我只有一处没有使用默认值,仅仅为了显示一些简单的应用到服务的绑定,这一处输入 1,即选择 mongodb 服务。

Would you like to deploy from the current directory? [Yn]: Y
Application Name: some_app_name
Application Deployed URL: 'you_test_subdomain.cloudfoundry.com'? 
Detected a Node.js Application, is this correct? [Yn]: Y
Memory Reservation [Default:64M] (64M, 128M, 256M, 512M, 1G or 2G) 
Creating Application: OK
Would you like to bind any services to 'gvp_node_test'? [yN]: y
The following system services are available::
  1. mongodb
  2. mysql
  3. redis
Please select one you wish to provision: 1 Specify the name of the service [mongodb-55666]: Creating Service: OK Binding Service: OK Uploading Application:    Checking for available resources: OK    Packing application: OK    Uploading (0K): OK Push Status: OK Staging Application: OK Starting Application: OK

即使实际上不需要安装数据库,我这样做的目的是为了说明安装一个服务是多么容易的一件事。此时,我们已经有了一个运行中的应用,可以使用 curl 证明它已经运行:

curl your_app_name.cloudfoundry.com

上面的命令会获得响应:“Foo,I’m alive!!”。就这样,应用部署完成了。一共只有安装、选择目标、推送这三步。

现在,让我们看看可以对应用程序做哪些事情以及 Cloud Foundry 环境。

更新应用无需重启

有一些事情需要定期去做,如更新、重启和推送应用。具体工作包括:

推送应用:

vmc push blaghApp-v1 --url blaghApp-v1.cloudfoundry.com

检出实例:

vmc instances blaghApp-v1 1

取消映射应用实例:

vmc unmap blaghApp-v1 blaghApp-v1.cloudfoundry.com

通过下面的命令组合进行回滚:

vmc map blaghApp-v1 blaghApp-v1.cloudfoundry.com
vmc unmap blaghApp-v1 blaghApp-v1.cloudfoundry.com

停止同一已映射的应用程序:

vmc stop blaghApp-v1

还有很多其他的命令和选项。更多内容请访问: http :// cloudfoundry . org .

与框架和服务相关的更多材料

对于 PaaS 来说,其关键特性之一就是要支持一个或者多个框架。下面是 Cloud Foundry 和 Iron Foundry 联合之后为用户提供的主要选择。

Node.js

Sinatra + Rails

PHP

Java

ASP.NET

使用像 AppFog 这样的服务,我们能够进一步抽象 PaaS,提供许多新的接口和命令。即使 AppFog 会提供 Cloud Foundry 的所有功能,AppFog PaaS 也将会进一步的扩展 Cloud Foundry 以提供额外的功能。

工作原理

到目前为止,我们已经介绍了基础内容,概括了 PaaS 为那些准备使用它的公司真正提供的功能。下面我们深入介绍是什么造就了如此巨大的飞跃。

PaaS 内部

作为服务提供者的平台内部含有很多底层的内容,这通常会让它变得非常复杂。它需要有自恢复能力,能够启动和停止服务器实例及相关的功能。所有的这些事情都需自动化,尽可能少的人工参与。.

下面是 AppFog、Stackato 等提供平台服务的公司所使用的 Cloud Foundry 和 Iron Foundry 软件的一个简单的图表。

(点击放大图片)

架构元素——Cloud Foundry 核心系统架构

Cloud Foundry 系统的核心和 Iron Foundry 的附加功能都围绕着控制器。通常我们将其称之为“控制器的概念”,使之与其他十几个使用相似术语的模式区分开。控制器是自恢复的,能够在一个平台架构中多次使用。

围绕控制器有很多控制辅助技术,例如 Resque 和 Stager。NATS 提供的 pub/sub 功能可以充当这些组件之间的粘合剂,并赋予它在这样的系统中所需要的弹性。

架构元素——Droplet 执行引擎

Droplet 执行引擎(DEA)是一个程序,它能够简化部署并启动 Apache 或其他服务器上的代码。它们的工作是执行最终用户的代码。

DEA 是跨平台运行整体架构的一部分。它可能包含 Node.js、Java,Iron Foundry 是为.NET 扩展的 DEA。DEA 可以有很多,配置也不同,这样就能根据它们原定的用途完美地为特定的实例分配大小。

架构元素——路由和健康管理器

路由好比系统中的事件守护进程,其责任是监听将要激活的新应用。而健康管理器的作用是识别任何可能产生的问题,并通过告知控制器或者其他机制来解决这些问题。

架构元素——服务

在 Cloud Foundry 中服务是最好的扩展点之一。在这个领域内有很多扩展,例如 MySQL、Redis、SQL Server 等。

架构元素——将来

尽管 Cloud Foundry 是经过深思熟虑的,但是它依然有许多最终特性需要实现。例如,许多企业的用例依然需要诸如审计、认证和编排之类的功能。毫无疑问,有其团队在背后的支持,Cloud Foundry 在不久的将来将会新增很多特性和功能。

如果想要更深入的了解架构,可以查看 Derek Collison 的描述" Cloud Foundry- 技术内幕".

DevOps,进入 NoOps

从架构设计中我们能够发现,仍然有大量的需求,要求 PaaS 供应商提供强大的 DevOps 方面的支持。但是,随着这种形势的巩固,它会驱动 DevOps 转向 PaaS 提供商所提供的更加精密和集中的价值。但是在小企业、中型或者任何 PaaS 用户的外部和内部,它能够提供一个条件使 DevOps 角色转变成提供商,使业务的核心竞争力聚焦于应用和需求。随着这种转变,最终会进入 NoOps 的时代,更加专注于业务、干净的应用开发、更短的周期以及始终难以捉摸的敏捷性提升。

你准备好 NoOps 了么?让我们知道你的想法,  @ adron 和  @appfog

关于作者

Lucas Carlson是 AppFog 的 CEO,该公司由他在 2010 年 9 月创建。在 AppFog 之前,Lucas 领导了 MOG 的开发,一个使用 Ruby on Rails 和 MySQL 创建的基于音乐的、流行的 Web2.0 社区网络应用。在 MOG,他编写了大部分代码,创建了一个能够随社区的增长而扩展的架构,同时还雇佣、领导并发展了一个技术团队。MOG.com 现在是 Web 上最流行的五个 Ruby on Rails 网站之一。他写了十几本 Ruby 的书,包括 Ruby Cookbook,同时还有各种其他的贡献,包括 Rails 和 RedCloth。Locas 参与了多个业界组织并在全国各地做定期演讲。

Adron Hall 是一个软件架构师兼程序员,自 2007 年以后从事云计算服务,他使用大数据,利用从商务智能转到基于文件的数据存储内部的阵列结构的小知识为定制软件需求提供缓存层的服务。现在,Adron 倡导使用云技术、构建更好的数据中心、使用最好的软件开发实践,保护金融业所有内容的安全。


感谢马国耀对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

评论

发布