评估云计算厂商的DevOps工具和模型

奔向云计算的笨鸟 2012-06-14

大多数云计算服务供应商都不会认为,最有利可图的云计算战略是锱铢必较地按小时出租基于云计算的CPU周期或平台服务。软件即服务(SaaS)可能是三大云计算业务模式中最引人注目和最具盈利能力的,因为它为客户提供了取代大部分技术支持类型成本的功能,并可直接销售给消费者。

但是SaaS的成功并不是一帆风顺的。如果不使用DevOps工具和原则,那么建设和维护SaaS应用程序的任务就将快速成为云计算供应商们的运营噩梦。这些问题的最大来源在于:为部署在云计算环境中的服务实现全生命周期过程的自动化。

云计算要求新的配置策略

在云计算的早期发展阶段,SaaS部署的很多工作都必须通过手工或开发内部自动化软件来完成。对于运营商们来说,其相关成本是相当高昂的,同时也会造成他们的客户有服务质量不稳定的使用体验,但是一个新的策略是有可能扭转这些趋势的。

云计算供应商在设计服务之后的传统做法是开发他们自己的运行工具,这意味着这些工具必须进行定制以便于适应每个应用程序或应用程序组件的要求。这完全是一个低效且拙劣的过程。更新这一模式要求供应商在应用程序开发过程中开发用于云计算开发的工具,把开发和运行整合到同一个生命周期中。这一概念被称为DevOps,这个术语的就是源于开发(Development)和运营(Operation)。DevOps工具和原则并不仅限于云计算,但是似乎他们是在云计算时代中出现的。

所有DevOps应用程序都是一个配置引擎和一组应用程序编程接口(API)的组合,而API可连接应用程序以管理接口,从而用于设置云计算服务、私有服务器以及网络管理系统。应用程序需求描述可驱动配置引擎;在运行时,这个引擎可根据应用程序描述来开发管理命令。这些命令可对应用程序进行设置,以便于应用程序能够正确执行。

在一个成熟的DevOps环境中,开发人员可根据应用程序来编制配置说明。但是,DevOps工具和方法现在正在被使用,它可允许开发人员对已开发完成的应用程序生成配置说明。

DevOps工具:脚本程序与容器之争

DevOps工具有两种可能的模式:一种是纯脚本程序模式,而另一种是容器模式。

基于脚本程序模式的DevOps工具将会让Linux用户感到非常熟悉,这是因为它们允许保存命令,并使用可替换参数运行。大多数的流行商用配置自动化产品和管理自动化产品都属于这个基于脚本程序的模式。其中包括微软公司的Windows Azure PowerShell CmdLets、Amazon Web Services的CloudFormation,以及一个开源Opscode开发项目Chef。

而容器模式则是创建应用程序的一个抽象,我们可称之为容器、对象。然后,配置引擎就处理这个容器以便于发布命令。在众多基于容器的DevOps工具中,只有一个被广泛采用:开源项目Canonical公司开发的Juju。使用Juju的容器模式可实现最大的承诺。

Juju的好处

容器模式的优势在于它允许云计算供应商建立一套描述应用程序部署和生命周期的可重用控制,并在需要的时候运行。

这一点远不同于基于脚本程序模式,后者要求供应商把应用程序需求(也被称为特定域语言,DSL)翻译成为脚本程序可替换的参数。这可能需要通过脚本程序跟踪应用程序的变化,以确保应用程序仍然能够正确运行。

相比较而言,Juju的目标在于使翻译任务成为一个纯粹的政策说明。这意味着云计算供应商能够潜在地赋予用户一个进行定制化和设置的角色,对于供应商来说,这使得应用程序描述的维护工作更为轻松了。

Juju是开源的这一事实也使它适合于希望定制化工具以支持他们自己服务计划的云计算供应商,但是还有大量其他的开源可定制DevOps工具和项目正对Juju的地位提出挑战。其中具有代表性的有 Dell开发的Crowbar、OpenStack的 Donabe项目,以及Canonical的Ubuntu Orchestra。虽然开源增强总是一个选择,但是云计算供应商最终将从那些综合性DevOps工具中受益,这些工具能够提供正确的功能,关注于开发脚本程序和容器。

使用DevOps工具销售SaaS

云计算供应商应当从在开发应用程序时就为应用程序设置DevOps配置需求入手,开始实施他们的DevOps战略。这通常涉及所有的配置规则,其中包括软件实例、数据库实例以及网络寻址的多个设置规则。不同DevOps工具的功能在这些领域中都是不同的,因此针对项目功能和工作计划审查应用程序需求就非常重要,这样可确保所有一切都在朝着正确的方向发展。

相关推荐