DevOps, PaaS以及他们之间的一切

2016-02-20 17:20:00
寄云科技
翻译
3422
摘要:对DevOps以及PaaS的简单对比


这个月AWS宣布了OpsWorks(译者注:这篇文章是2013年3月份的文章),这是他们在收购了Peritor,并且将其Scalarium平台融入到AWS中的成绩。OpsWorks是一个为在云端部署应用而提供的全新的框架。


虽然AWS已经有了不少其他的框架来实现自动化的应用部署,比如CloudFormation以及Beanstalk,我还是发现了AWS将OpsWorks增加到PaaS和自动化框架(Chef)之间的重要性。


在这个博客里面,我将更细致的分析PaaS和DevOps之间的差距。


我前几个月之前写过一片博客“PaaS,破局者”。在那篇文章里面,我指出在云端交付应用有两种模式,PaaS和DevOps。在这篇文章里面,我建议不要把这两个模型当成两个独立的实体,而要结合起来看。


Jame Urquhart以前在GigaOM上发表过一篇非常有名的文章,“你的PaaS是组合型(Composable)的还是上下文型(Contextual)?”。在这篇文章里面,Urquhart指出,PaaS有两种:组合型的和上下文型。典型的上下文型PaaS,如一些基于插件的实现方案,包括Heroku和Force.com。插件可以提供一个很便捷的平台扩展的方案,但是扩展需要满足一定的模型要求。比如,你在Heroku上,你不能控制实际的VM或者底层的云基础架构,以及相应的网络。相反,组合型PaaS的实现方案,则主要关注不同的应用组件之间的组合关系,因此,它们不需要做出任何关于底层基础架构的假设。Amazon的OpsWorks就是符合这个特点的PaaS。


Urguhart还特别指出了Dietzler的Access规律,作为佐证上下文型PaaS局限性的根据。虽然上下文型PaaS提供了很强的灵活性(基于插件实现定制化),但是你仍然有10%你最关心的东西你控制不了,而正是这10%决定了你是否会采用这种方式来交付你的应用:


每个Access项目最终都将失败。这是因为,尽管用户想要的东西当中有80%在创建起来很快并且也很简单,还有10%也能做到但有难度,但最终会由于谁也无法超越内建的抽象机制,那剩下的最后10%不可能完成,可用户总是想要得到100%的他们所想要的东西。”


很有意思的是,AWS在这篇文章发布之后一周就发布了OpsWorks。

AWS在它同Heroku/GAE竞争的产品Beanstalk发布之后两年发布了OpsWorks。我找到了一篇有意思的Amazon的通告,解释了为什么他们在有了一个PaaS之后仍然还需要发布一个新的应用交付的PaaS平台:


  • 承认当前PaaS不是一个适合所有用户的方案。尽管AWS在这个平台上提供了很多扩展来支持不同语言,仍然还有很多应用,以及相关的组织的需求,无法用Beanstalk来满足。
  • 认识到在应用交付的领域,需要有一个更开放的框架来交付应用,并且这个领域需要一个组合型的方案。在OpsWorks里面,组合型的实现方案依赖于Chef,而OpsWorks则在Chef上提供编排能力。


在Werner Vogels的博客里面,他使用“控制 vs 方便”来描述AWS的不同解决方案。

“在AWS发布了OpsWorks之后,客户现在可以有一个强大的解决方案,在不需要牺牲可控性的前提下来轻松管理他们的应用。”

而有意思的是,我之前采用了相似的术语,“控制 vs 生产力”,并从更广泛的IaaS和PaaS的角度来描述不同的解决方案。


OpsWorks和其他的PaaS

在我上周和Ran Tavory以及Ori Lahav的一次讨论中,我们似乎都认为当前这两种模型,组合型和上下文型,都有存在的必要。但当我提出“哪一个PaaS方案会在未来运行80%的应用?”的时候,我们都认为应该是OpsWorks这样的组合型PaaS。让我仍然坚持现在会有两种PaaS的原因在于,现在只是一个过渡阶段,而随着时间的迁移我们会发现第一代的PaaS以及Beanstalk类似的PaaS,都会被第二代的PaaS,也就是OpsWorks这样的PaaS,所取代。


OpsWorks,以及IaaSPaaS之间的模糊界限

OpsWorks运行在Chef之上,提供了很多云基础架构提供的IaaS服务,这产生了另一个问题,即“是否还需要在IaaS服务和应用之间做一个清晰的界定?”。我的另一篇博客也提到了这一点,“PaaS和IaaS之间的模糊界限”。


OpsWorksCloudify

OpsWorks和Cloudify都遵循相同的架构设计原则。两个方案都紧密集成了DevOps的工具(如Chef),并且在其之上增加了一个编排层,让用户可以轻松的编排应用栈(Stack)需要的各种组件。在很多场合,你可以认为Cloudify就是你私有的OpsWorks。


PaaSDevOps以及他们之间的一切

Vogels似乎不愿意将Beanstalk或者OpsWorks打上PaaS的标签。相反,Urquhart将这两种PaaS分成了组合型和上下文型。


我能看清楚的一件事情是当前的PaaS空间过于狭窄,不允许存在这么多的PaaS种类。


从更广义的语义范围来看PaaS的定义,我认为PaaS应该是“在云端运行和管理应用程序的平台”。在这个语义下,我们选择运行应用的方法只是一个实现的细节。而有了这个概念之后,我尝试把Beanstalk和OpsWorks看成是两种不同的PaaS方案。我们在这一点上缺少的知识如何定义这两个种类。


一种方案是采用Urquhart的定义,即“组合型和上下文型”,即根据他们如何交付应用的方式来划分。另一方面,我们也可以将CloudFoundry vs GAE看成是开放的和封闭的。还有一种分类方式是私有PaaS和自服务PaaS。


相反,RightScale采用了Cloud Application Management的定义,并且将PaaS看成是一个采用Cloud Application Management的私有的应用方式。我们Gigaspace内部也有针对这个话题的讨论,也不能对合理划分PaaS种类达成一致的意见。


你认为呢?OpsWorks是一个新型的、组合型的,或者Cloud Application Management的平台吗?


这一点真的很重要吗?


发表评论
评论通过审核后显示。
新增底部228