BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Stu Charlton论云计算
录制于:

| 受访者 Stu Charlton 关注 0 他的粉丝 作者 Ryan Slobojan 关注 0 他的粉丝 发布于 2009年9月16日 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。
27:25

个人简介 本视频由黄璜翻译,马国耀审校

Stuart Charlton是Elastra的首席软件架构师,这是一家提供云计算软件基础设施的公司。Stuart在系统架构,RESTful Web架构,数据仓库等方面都术有专攻,他还是把精简与敏捷的方法应用于业务流程及产品开发的积极尝试者。

QCon全球企业开发大会是由C4Media媒体集团InfoQ网站主办的全球顶级技术盛会,每年在伦敦、旧金山、北京、东京召开。自2007年3月份在伦敦召开首次举办以来,已经有包括金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

1. 大家好,我是Ryan Slobojan,和我在一起的是Stu Charlton。Stu,让我们来谈谈云计算。传统的托管供应商与云托管有什么不同呢?

传统的托管供应商通常不是向你提供...多租户的机器,你可以在他们预先安装和设置好的机器上运行软件,并且支持你运行各种web应用或者数据库等等,就是允许你在托管环境里专门分配一台机器,通常按月支付月租费,从而获得相应的SLA。

而另一方面,较之传统托管,云计算在实际预估需求所用的耗时上有很大的差别。首先,由于实际上使用自服务的接口或API来提供机器,启动和回收一台机器的引导时间缩短到了以分秒计的程度。第二,如果你的需求有着太多的变量,你可以使用你的云来灵活分配。比如说,由你在云服务商那里获得的限额而定,你需要的时候,可能在一周内将服务器从30台增加到3000台,而在传统的难以拓展的托管模型中,你不得不给他们一再地通知:“嘿,我可能会需要3000台服务器”,而他们会回答你:“请给我们两个月”。

一个主要的不同之处在于云服务供应商更愿意做他们自己的容量分析与需求趋势,当然是在一定的限额范围内。这很重要——运转机器与停止机器的能力,以及完全基于使用的收费。我认为这里面还有更多的价值。话说回来,实际上你会发现,如果将在传统的托管方式下运行一台专用机一个月与在云中部署纯粹从成本进行比较,许多的云服务——至少现在——的确显得有昂贵一些。现在有了“外包”云服务,不是指仅仅关于外包的云,实际上是关于你是否在自己的数据中心里拥有它以及进行费用退回。而是你真的能够通过它来缩短时间,比如,我想部署什么,不管是在自己的数据中心或者是其它的第三方共享托管或者是Amazon EC2之类的。我形容...它是如此之快——这就是云服务不同与其它所有事物的地方。

   

2. 你对于不同的云计算产品有什么样的看法?

对于云计算是什么有着广泛而多样的定义,这已成为不变的主题了...所有这些技术热潮都有着不同的趋向...当市场与它们联系起来的时候你发现那里充斥着多种多样的定义。我认为云计算有两种不同的极端。一种是平台云计算,有人为你创建好了一个完整的系统供你使用——这是一个黑盒子,我常这样开玩笑。这就像是,你插入你的代码,它非常面向开发者和终端用户,就像你看到的SalesForce或是Google App Engine那样。

对于一些特定的应用点或者独立的应用,这非常合适,你可以做CRM,做帐,故障通知等等之类的工作,也许你需要在后台做一些集成,但这都是一些自包含的事情,这样一来,支持服务于下载的应用交换并且提供一个可工作的开发平台就显得很有意义。但这将高度依赖于所暴露出来的这些能力,而API及其暴露方式也将让你受到限制。

但它们大多有自己私有的SQL版本,事实上还不能算是SQL,因为这些版本只拥有标准SQL的一小部分特征。这种云的特点是“你所有的基础都是我的”,它对于很多这类的应用程序来说将十分有用,但是,我不确定它对于那些大公司而言用处有多大,特别是那些有很多已有应用,且并不打算重写它们的大公司。

这就将我们带到了云计算的另一个极端,那就是面向基础设施的云计算,或者说,基础设施即服务(infrastructure-as-a-service)。我不确定你怎么读它,IAAS什么的,没关系...这包括了...其典型代表是Amazon的Elastic Compute Cloud,它背后的意思非常接近系统管理员或者说是数据中心的运营官,在这种情况下你所做的是自动的分配存储网络容量与计算能力,通常伴随着一些事先定义好的软件包。它的一个好处就是能够有效的支持你现在所使用的东西,你可以将你到现在所做的大部分工作,包括现有架构,软件等等,都迁移上去。

这可以类比到一个供应链的生态系统——软件行业仍然存在,并非所有的东西都是...软件并非仅仅是服务,仍然存在真正意义上的软件,你可以分发它们并且把它们安装在云上。像“架构师们不断寻找处理问题的最佳方案”这样的生态系统仍然存在。话说回来,当你工作于基础设施云之上的时候,你不会得到像平台云服务那样的开箱即用的伸缩性,因为你需要设计自己的系统以让它可以达到你需要的伸缩性。

有人说:“云计算就意味着无限的伸缩性”,这可能是一种谬误,因只有你将系统设计成这样,它才会有这种能力。你实际上会看到很多分析师出于这一目的声称平台云服务最终会赢得市场,因为这种黑箱的方式让你不必有太多考虑,而它自己会像变魔法般的实现伸缩。对于这一点我认为:“当然很好,只不过我还有巨额的按照特定方式设计的遗留系统的投资”,因此这里就说到了企业的真正好处在于它能够真正的降低交付周期以及降低收费,因为就算是与许多本地场所的数据中心相比,这种伸缩的经济效益比如Amazon也是非常有优势的,他们是这一低端企业的主导者,并正在积极扩大空间。

   

3. 你觉得云计算将怎样改变软件的开发与部署?

云计算最重要的一点是...有句老话说得好,“当你解决了问题1,问题2就被提上日程”。现在实际分配后台的数据中心资源已变得十分容易了,我们将拥有更多的这些资源。以前可能是100台服务器的,现在可以是1000台服务器了。有这样一种说法,我们将会降低利用率,所有这些都将被合并起来,然而...我也同意,虚拟化以及其它的一些技术可以帮助云计算做到这一点,但如果你给了某人实现某种东西的能力,他们可能会利用它或滥用它,因此我们需要管理的东西将比以前多得多。

“IT服务管理”有着许多传统的挑战,正如这一术语所表达的,可能是配置管理,而主要是处理需求管理;这又是另一个不同的世界,它来自于运维行业——他们来自于英国的商贸部办公室,创建了ITIL(IT基础设施库)。这虽然看似官僚,但却是考虑缜密的管理IT的方式。

当你进入到云计算这样的方式的时候,这些问题被提到了一个十分重要的层面,因为我们有这么多需要管理的东西,尽管以前它们是以一种随意的方式,或是非正式的方式,或者是取决于你的组织的某种非常官僚的方式而存在。我认为正是因为挑战的存在才使得大家对它如此关心,因此,我们过去在软件上所做的许多工作,有许多...特定点解决方案(point solution)来管理复杂性。如果你是一个开发者,在构建系统时你通常需要组合一些依赖管理器,比如Maven或者Ruby社区的 Capistrano又或者是Ant等等——这些社区都是很不错的,但它们不能处理像“好的,我已经把软件打包好了,它们各有各的设置,有一些可能在配置文件里,有一些可能在SNMP,有一些可能在JMX里”这样的总体情况。关于如何设置这些有着一堆的标准,而小型的特定点解决方案也有很多。我的组织里正在致力于的一件事就是尝试创造一种统一的形式以超媒体的方式来描述它们,这样的话我们就有能力让你的软件以这样的方式来描述,可以处理所有这些麻烦的问题,并且独立于你想要分配的数据中心或者云,不管是你自己的或者是场外的公共云。

我认为这里有一个隐秘的酱汁理论(sauce theory)——Google的隐秘酱汁理论——云计算所做的重要的事情之一就是消除IT,并且减少对IT的依赖,因为一些神奇的架构会使IT变得更可管理。实际上我认为将要发生的事情完全相反——我们得把我们以前对于IT所有的想法完全打包起来并且抛到脑后,这将会是一个大事件,并且软件将会因此而改变。

   

4. 我们如何既能使用云计算与此同时又能避免与厂商的绑定呢?

这是一个很好的问题,现在这个答案很不好说,因为就目前而言,在某种程度上你不能有效地达到这个目标。每一个云服务都有它自已的私有元素。就像我之前提到的那样,平台云计算有着各种不同程度的私有性,尽管其中有一部分云服务将在一定程度上基于标准的基础设施作为了它的一部分。如果你看看Google的话,他们提供给了你一个Python引擎,你可以在你的Web应用里面使用一些标准的Python框架比如Django等等,这非常棒,但他们的底层数据库层,是对他们的BigTable技术的一种封装,是以他们自己的SQL语言来做的,这就局限了你能做的事情,举例来讲,如果你想要把你的应用移植到本地场所的服务之上的话,实际上你无法做到。这种模型有一定的局限,尽管我相信随着时间的发展它们会有所改进。而如果是基础设施的云服务呢,其真正的基础设施是可以良好移植的,就像linux机器或者OpenSolaris或者Windows,或者任何你使用的机器。

从这种意义上讲所谓绑定就少得多了,但目前而言启动机器的API仍然可能是私有的,因为在这一领域还没有标准,但这是好事情——我的意思是,这还是一个新兴的领域,如果你愿意的话,这些小公司需要时间来发展不同的管理云服务的方式。我认为,目前而言真正要保证的是要分离构建软件的方法与提供资源的方法,这样至少在所谓的锁定方面你可以保持一定的模块化:资源提供模块,管理模块,还是软件本身呢?我经常向我们的客户或潜在客户提出的另一问题是,“就算是在这些基础设施的云服务上,到底要我如何改变应用?”我这样问的意思是,应用的改变不会太多,但是他们往往具有局限性,因为他们所做的事情较之传统的数据中心而言是基于一系列不同的假设或前提上。

这里有一个关于灾备的极好的例子——如果让我举例的话...如果我有一台容错的,或者说是高可用,或者是集群的机器,通常失效是发生在应用层上,而这层通常有一个负载平衡器或者是智能代理等等这样的工具,它将会处理这样的问题:“如果这台机器宕掉了我就会找到另一台机器”的情况,但接着你就会遇到灾备的问题,“好了,现在这台机器再次恢复工作了,我要将它重新加入集群中”。如果是传统的数据中心,通常的做法是替换物理机器。因此你要到数据中心所在的房间,将东西拔出来,换一个新的东西上去(比如一个新的硬盘或者其他),它将会使用它一直使用的IP地址和路由信息。在云计算中,因为我们有软件来处理这些,新的机器有可能在数据中心的另外一个地方。

如果我要给它分配IP的话——就像Amazon的例子一样,他们有这种弹性IP——这将会需要稍微长一点的时间,因为新IP必须要重新路由网络才能处理,“这是我的IP”,而且要实际指向数据中心的某个区域,原因是内部 IP是不一样的,而它属于不同的段,不同的交换器,要统一处理。

有没有其他的方法也可以做到呢?我们在处理多租户的环境时有许多细微的差别,因为在这样的环境里你不能做出实际的预测...而好处仍然是,灾难恢复的时间要快很多。所以在某种意义上,我的环境里灾难恢复的平均时间也比更换机器的手动恢复要快得多,但没有热备份的私有刀片阵列那么快,而是介于两者之间。但这是云计算会带给你锁定的一个方面,因为这是一种不同的思维方式。

另一个方面是他们可能限制你使用某些网络中你已经习惯使用的某些特性——一个经典的例子是,目前在Amazon上,你无法使用UDP广播或者IP多播。而这有时就会带来一些问题,例如,使用会话复制的应用服务器。如果你将应用服务器设置成点对点的——TCP,它可以很好的工作并支持会话复制,但如果你依赖于 IP多播来做的话,就会遇到问题,因为它不支持这样做。我觉得大多数的限制所带来的架构改变不像所意识到的限制那么多,而且还提供了替代方案,因此它是可解决的,它只是...在本质上它不是一种改写。

   

5. 我们如何从现有的系统,部分或完全地转向云计算呢?

事实上我认为往往会发生相反的事情,接下来我会做出解释。首先,我认为在现实中有这样几个云计算的用例。有这样一种业界的鼓吹:“所有的事物都会移到外包的云服务上”,我和我们的CEO经常和客户开玩笑说CIO的枕头下总会藏着几张DVD的软件拷贝,这样他才会安心。没有必要将所有的东西都移到外包于某个地方的云服务之上,但我再次重申云计算并不仅仅是外包而已。

我们来谈谈外包,对比一下“我在本地运行的”与在“因特网的云服务上的”。如果你思考一下企业是如何运作的,他们在某些情况会表现出来那种保守。而他们愿意的例子是...我认为在云中进行测试开发是比较有意义的,因为你处于一种迭代过程之中,不想被别的东西所妨碍,也不想因为基础设施的原因而减缓进展,而且这个阶段也没有质量或SLA方面的考虑,因此我同意在这里云服务是一个绝妙的使用用例,特别是当你在做压力测试或者负载测试的时候。

它的妙处在于能让你真正的用100台服务器来做有代表性的压力测试,只需数百美元,与之相对的是花费成千上万的美元去租用服务器。所以我认为这样的事情将会普遍发生。特别是售前,我们对企业软件的概念验证所做的许多工作都花费了很长的时间——很多个星期——并且存在很多问题...问题不在于POC实际实施的过程,而在于搭建环境的后勤工作。云计算对于助力售前人员开展和运行POC 的工作上起着很大的作用。

这里有一个术语叫做“云爆”(cloudburst),意思是“需要将数据中心的能力扩展到一个公共云上以处理高峰时刻或者短期蜂拥的请求”,如零售商在圣诞节可能遇到的情况一样。我非常赞同,我想这就是弹性云真正能够发挥作用的地方,取决于需求的弹性,我们可以增长或者缩减——我想这会表现得非常好。但你回到我开始的关于开发测试的例子,比如压力测试,最终会发生的是,你以云计算开始,因为它很容易也很灵活,但当真正生产的时候我实际上认为你会出于多种原因将你的应用移到内部,比如你自己的数据中心或者私有云之上,私有云可能运行于某种虚拟基础设施之上,比如 VMWare,Xen或者Hyper-V。

现在绑定问题真正变得重要了,比如“行了,我可以肯定我能在某处的云服务之上运行我的应用,但我同时也需要在内部运行它”,也许是出于隐私条款的考虑,萨班斯法案的考虑,或者仅仅让我我感觉更舒服,因为自已管理和运维私有云的成本和运行在别人提供的云上相比,不会多太多。随着时间的推移,现在这些可能发生改变,可能会出现如果不把应用运行于某个外包的云服务之上就会显得非常被动的情况。但我想至少在未来五年,云计算对于企业来讲是非常实际的,但将会是以一种“我由云计算开始,再移回内部”的方式,与向外移出的方式相反,除非在某种情况下你要处理 “云爆”(cloudburst)的情况。

   

6. 在现在的经济情况下,你认为云计算如何帮助中小型企业与大型企业展开竞争?

这是一个很好的问题。我认为云计算所带来的一个巨大变化是运营开支。之前是资本开支的项目现在变成了运营开支,而且预投资的量也少很多。它的负面影响就是许多大型的企业更愿意做资本投入,因为随着时间的流逝它可以分期的收回成本,而运营开支就完全是开支了。

另一方面,小公司,特别是没有太多资本的公司,肯定愿意利用这种快速启动和即用即付的运营开支模型的能力,因为这有助于他们的运营风格。我想比较有意思的是静观经济条件如何影响到云服务的定价。另一值得观看的是云服务提供者是如何合并的,在我看来最后剩下的将是几家大的竞争者—— Amazon,Google,微软,还有一些其它的竞争者会冒出来——IBM有他们的蓝云,他们在这方面做了很多。我想他们会生存下来的。

还有很多中等水平的竞争者,并且我也非常尊敬,但我并不认为他们能在这样的条件下存活下来,因为这是一类底层业务...就像是零售业,我认为只有大的零售商店能够成功,而他们都有各自的市场。因此我想在云计算行业最终会有某种清算,最后会发生的是,就像因特网服务提供商的情况一样,如果你想一下90年代有许多作坊式的因特网服务提供商——现在某种程度上仍然存在一些,那些比较成功的——但最后它们最终都被收购了,而我们现在的因特网服务提供都来自于大型的电讯企业或者有线媒体公司。

我想在云计算领域会发生同样的事情。我不认为会有一家或两家,我觉得可能会是五家以上,或者比这个少一点。同时会有一些市场划分,我想小一些的云服务供应商想要生存的关键就是要找准市场位置,或者是关注于垂直应用或者是平台即服务(PaaS)型的云计算,而不是以基础设施为中心的云计算,因为这已经是底层的业务了,这样他们或许能获得很大的成功。如果成功,它不仅将影响他们的客户,而且也将会影响到新兴的行业的其他提供者。

一个好处是,软件供应商也开始创建基础设施了,云计算的中间层,以使得云能够更快的分配和管理。我想这就是真正会生存的东西,因为它有助于破坏锁定,它有助于帮助在各个云之间创建一致性,当然形成标准需要花费一些时间,因为这需要由市场来挑选它最倾向于的解决方案。

   

7. 你认为工具在帮助提升云计算产品的采用方面起到了怎样的支持作用?

我想就工具来说话是一个不断发展的问题,但对于各种各样的战略而言却有很多可以谈的。一方面我们可以看到Google很好的利用了Python工具以及框架还有整个社区,这非常不错。也有一些初创公司,比如EngineYard,这是Amazon投资的公司,同时还有我们Elastra。 EngineYard利用Rails做了一些非常有趣的工作,并且他们在创建一个可移植的云计算环境,如果我没记错的话,是将Ruby和Erlang组合起来创建一种新的体验能够让Ruby开发者真正的开始一种可伸缩的可恢复的云服务。再一次,这是定位于平台的层面,关注于开发者,这非常好。

我想很多先行者可能将会是开发者。另一种更有意思的方式是我最近看到的微软在Azure上面的一些工作。当然喽,微软有着很多的资源,所以当他们看见 Google与Salesforce.com以及其它的云计算供应商所做的事情之后,他们会说:“我们有这样一个平台,它专注于开发者,而微软是一家一直以来都非常关注开发者的公司。”

而你又会发现Amazon有着一个非常受欢迎的基础设施服务,于是微软就会说:“好的,让我们两手都抓吧”,于是他们开始覆盖整个市场并开始和每个人竞争,但他们所带给开发者的角度是.NET,意思是对.NET开发者来说,云计算真正所做的是使得部署和分配.NET应用变得非常的容易了。

还有一件事情要说...长期以来对微软的基础设施比如BizTalk或者SQL Server以及这一类各种各样的服务器的指责就是他们比较难以安装和操作,因为有太多的安装组合并且还要按一定的顺序,还有补丁等等。当你再看他们用 Azure和.NET服务开始尝试所做的,就是在云计算上提供更丰富的开发者体验,这不仅能保留他们的.NET开发者用户群,同时还使得微软的云平台成为了你启动开发的顺理成章的选择,不论最终会部署的环境是什么。

所以我认为他们为大家带来了一个非常有趣的视角,也非常适合他们的世界观。当然,Amazon允许你运行几乎所有的基础设施,不管是Java,Ruby,Python还在现在的.NET,因为你可以在EC2上运行 Windows,因而他们更关注于这些机器的管理和存储方面,而不是真正的关注在开发工具上,但这从另一方面创建了你在传统的软件行业里面所拥有的一种生态环境——所有在传统的软件行业里面有的,在它们的环境里都有,所以这是一种更为开放的方式。我想还是会存在所谓的陪审团来评判哪一种方式对于开发者而言最好,而且不只是开发者,还有更多企业的决策者,影响者或者企业架构师也会在这些方案中表现出自己青睐的一面,管理员/运维员可能会更倾向于平台模型,因为这减轻了他们的负担,同时会避开基础设施模型,“哇,我有那么多要处理的东西”,或者可能出现相反的情况:他们可能会想:“我想要控制,我想能够处理,这是我的虚拟实例和存储”而不相信那种神秘的黑盒子。我想所谓的审判团还会存在而且这将是一个非常有趣的过程。

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT