求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
     
   
分享到
云计算--《云里雾里云计算》
 

发布于2013-2-26

 

目录:

1.云计算解决什么问题?

2.从Google集群到云计算,云计算的商业模式

3.Google云计算的矛头指向谁?

4.云计算大战,Google出招

5.是云计算,还是云存储?

6.安全性的难题,有解还是无解?

7.天上究竟会有几朵云?

8.云中说禅

9.赚钱才是硬道理

10.云计算的社会意义

11.赚点钱不容易

12.云计算经济学之现金流

13.云计算经济学之时间成本

14.云计算经济学之声誉成本

15.商机在于为人民服务

16.政策的猫腻

17.商战与和平崛起

18.结束

有一次去开会,台上的人在讲云计算。我问身边的听众,“听懂了吗?感觉如何?”

听众答,“云里雾里的,感觉特神秘。”

我说,“这说明讲员讲得好。有没有注意到寺庙里的气氛也很神秘?不神秘,就没有崇拜。不崇拜,你怎么肯掏钱买香火?”

1.云计算要解决什么问题?

1997年,Google的两位创始人,Larry Page和Sergey Brin,找Andy Bechtolsheim募集投资。

Andy问,“你们打算做什么?”

Larry和Sergey答,“打算把互联网上所有网页都下载,然后建一个搜索引擎。”

Andy说,”把互联网上所有网页统统下载?!需要多大空间?几个Giga不行吧,几个Tera也不行吧,几个Peta,几个Zetta?。。。嗯,我看几个Googol也许才能撑得住。知道Googol吗?就是10的100次方,就是一个1后面拖100个0!”

估计是Andy觉得这个项目不太靠谱,所以给的钱不多,只有1百万美元。只有这么一点钱,如果去买高端的存储系统,显然是不够的。走投无路的情况下,Larry和Sergey决定用PC之类便宜的机器,组建一个机器集群。先凑合着用,等以后数据量增加以后,再购买更多的PCs,扩大集群的容量。

这个故事的真实性,有待考证。但是从中可以看到Google集群,也就是Google云计算的核心,要解决的四个问题。

  1. 大规模的存储空间,用于存储海量的数据。
  2. 随着业务的发展,新的数据源源不断地增加,存储空间需要相应扩大。用术语讲,这叫可扩展性,scalability。
  3. 系统的硬件设备必须便宜,通常使用大宗产品(commodity),譬如PC,或者价格便宜,中等性能的Dell server。
  4. 便宜的硬件设备,经常死机。所以在设计这个集群的时候,必须保证不能因为个别机器死机,导致整个系统的崩溃。也就是系统的稳定性要好,reliability。

2.从Google集群到云计算,云计算的商业模式

起初Google集群是供内部使用的系统。Google为什么要开放这个系统,包装成云计算平台,给外界使用呢?

这要从Google的商业模式说起。Google的绝大多数收入来自于广告,其它产品和服务的收入十分有限。其它产品包括Google盒子,这是给企业内部网用的搜索引擎。把Google盒子安装到企业内部网,企业员工就可以搜索企业内部的文档,包括可以公开的文档,也包括仅供企业内部查阅的资料。虽然技术很新颖,但是卖得并不好。据ZDNet的报道 ,2008年度,Google盒子的收益,占Google总利润的份额,不到2%。

Google search appliance, 俗称Google盒子。

单一的收入来源,抗风险的能力差。譬如经济危机一来,各个企业的广告预算缩减,势必影响到Google的利润。怎么办?挖掘自身的优势,发现更多卖点,搞多种经营。

Google的技术优势在哪里?有人说,Google的搜索结果精确,所以PageRanking算法是其精髓。其实,算法容易模仿复制,即使几年前 PageRanking是Google的独家秘籍,但是今日各大搜索引擎,都有类似算法。

让Google独步天下的是它的集群。2006年,Google集群的规模 是45万台机器。两年过去了,有人推测现在的规模又翻了一番。由于Google从不公布准确数字,所以大家只能靠Google给硬件厂商下的订单推测。

推测虽然不准确,但是即便是10万台机器的规模,在历史上也是从无古人的,在当代也是独一无二的。而且,更重要的是这个超大规模的集群系统已经经历了 10年的实际运行,在实践中被证明,它是可靠的,是可扩展的,每台机器的价格也是低廉的。完全符合上一节列举的四个要求。

但是如何依靠这个独门神器挣钱呢?思路有两条。

1. 做hosting,数据托管。其它企业不用建自己的数据中心了,把数据存在Google的集群里得了,每个月交点托管费。

2. 不少Google的应用服务很有人气,譬如Gmail,Gtalk,Reader,Online docs,Picasa,Google earth还有YouTube等等。这些服务对于个人用户而言,完全是免费的。但是Google从来没有说给企业用户使用,也是免费的。譬如某家商店,开了一个网站,网站上需要贴很多照片,还要给个地图给顾客引路。这个商店不需要自己动手建照片存储中心,也不需要开发技术难度更高的地图软件,只要调用 Google提供的相关服务就好。商店建网站是为了赢利,所以Google当然要向商店收钱。

第二个思路还有个副产品,那就是给Google创造更高的流量。流量越大,说明观众越多。对于广告商来说,哪里观众多,就愿意在哪里投放广告。所以,如果第二个思路能给Google带来更高流量,那么会吸引更多的广告,给Google带来更多的广告收入。

Google的高管们一合计,觉得有钱途。于是乎,大张旗鼓地制造舆论,educate the market。

造舆论,讲究的是措辞的简练,气势的磅礴。这个新的服务叫什么? 用工程师的语言,准确地定义,应当是“超大规模的,可扩展的,低成本,但是高可靠性的服务器集群系统”。Google市场部的人一听,头摇得像拨浪鼓。不行不行,既不简练,也没有气势。

研究来研究去,于是乎,“云计算cloud computing” 这个概念粉墨登场了。

3.Google云计算的矛头指向谁?

有一次听一位IT业长者指点江山。长者说,“Google像一个阳光少年,一路顺风顺雨,张张扬扬。让人羡慕,招人喜欢。而微软像一个稳健的中年人,一路 风吹雨打,过五关斩六将,毁誉参半。对于它的支持者而言,它是令人敬重的领袖,对于它的竞争者而言,它是令人敬重的对手,无论如何,微软是令人敬重的。”

问及电脑的killer applications,长者说了三个,1. Email,2. Office产品系列,包括Word,Excel和PPT等,3. Web。Email和Web都是泛称,不特指某家公司的产品,但是Office系列是微软公司的产品。长者这样的表述,足见他对微软的推崇。

很少有人不知道微软,但是很少有人很了解微软。随便问两个问题,1. 微软哪一年成立的,2. 微软在哪个城市成立的,有多少人答得上来?

微软是在1975年4月,于新墨西哥州的Albuquerque市成立的,后来搬到了华盛顿州的西雅图市郊。从那时到2008年6月30日,Bill Gates掌舵了33年。然后把CEO的宝座让给了Steve Ballmer,自己则专心致志去散钱搞慈善去了。

Bill Gates舍得捐出自己绝大部分家产,这个心胸让所有地球人叹服。但是Bill为了保证他的基金会平稳运转,自己退休的同时,让微软一员老将,Jeff Raikes跟着他离开微软,出任基金会的CEO。Jeff Raikes离职,对于微软而言,是不可估量的损失。为什么这么讲?

微软有三个产品系列,

1. 大家熟悉的XBox游戏机,是微软the Entertainment and Devices Division的拳头产品。这个部门是微软从单纯的软件公司,扩张到家电行业的触角。虽然XBox的成功毋庸置疑,但是它能不能给微软带来丰厚的利润, 是摆在这个部门,尤其是其掌门人,Robbie Bach面前的巨大挑战。

2. The Platforms and Services Division,去年7月份被一分为二。一个专注于改善Windows操作系统,另一 个负责在线服务。原来的掌门人,Kevin Johnson,挥挥衣袖离开微软,去Juniper Networks出任CEO。

新的两位掌门人中,有一位是我们中国人,毕业于复旦大学的陆奇。从复旦毕业后,陆奇留学美国CMU,攻读博士学位。博士学位拿到后,经历了短暂的动 荡,1998年陆奇加盟Yahoo。他从工程师干起,扎扎实实,一路升到副总裁。2009年1月,陆奇学长离开Yahoo,出任微软Online Services Group的president。他的职责是,领导微软对抗Google。

2009年,争夺互联网霸主的大戏正式开演。

陆奇博士

3. 对于Windows操作系统的评价,好坏参半。但是对于Microsoft Office系列产品,业界基本上交口称赞。负责Office部门的原掌门人,就是刚才提到的Jeff Raikes。

Jeff Raikes

2009年上演互联网争霸赛,微软与Google双方的战略意图相当明显。

1. 微软以陆奇为主帅,强攻Google的核心业务,网络搜索。

2. Google砸重金推广云计算,挑战微软的拳头产品,Outlook email系统,和Office产品系列。

攻防战的关键,在于寻找对方的软肋。

[1] Microsoft Outlook vs Google Gmail

Microsoft outlook email系统的软肋,在于它的后台系统不够稳定,容量也不容易扩展。对于用户而言,经常会遇到Outlook服务器联系不上,以及存储空间不够的麻烦。

看准这两点,Google把Gmail系统的号召力定位在,1. 稳定性,2. 无限的存储空间。Google之所以敢于这么叫阵,本钱就在于云计算平台。

当然微软也不会示弱,它们反制的着力点在于保密性。

譬如有一家企业叫foobar,Google的销售人员游说到,“别用Outlook了吧,那玩意儿经常掉线,而且隔三岔五地骚扰你说,存储空间没有了, 请立刻删除不必要的emails。你的emails都很重要,怎么能删呢?用我们的gmail吧。”

Foobar公司的IT主管说,“我们公司的邮箱地址是@foobar.com,换成@gmail.com,不仅不方便,而且也有损于我们公司技术实力的形象。”

Google的销售人员说,“不用换邮箱地址,表面上看仍然是@foobar.com,用户也可以继续使用Outlook桌面工具,但是后台服务器被悄悄地换成了Gmail的云计算平台。”

Foobar公司的IT主管心思有点动摇。

这时候,微软的销售人员上门,说到,“听说你们想把email后台系统换成gmail?这可需要一点勇气。你们把公司所以emails,存放在 Google的平台上,万一Googler偷窥你们的emails,贵公司的商业机密,。。啊,哈哈。”

所以,为Google进言,欲挑战微软outlook,必先解决gmail的保密性。也就是其它公司的emails虽然存放在Google的云计算平台, 但是Google能够提供足够的技术保证,即便是Googler有意偷窥,他们也看不到。

[2] Microsoft Office vs Google Docs

Microsoft office 产品的软肋,在于所有文件存放在电脑本地。

譬如我在办公室写了一个设计草稿,通过email把文本发给一个同事审阅。晚上回家后,查看email,收到同事回复,说他做了一些文字上的改正,修订版 本放在email的附件中,同时建议多加几个插图。我加了几个插图后,文件尺寸变得很大,email发了很久,还是没有顺利发出。于是我把文件存在U盘 上,第二天上班后,拿给同事看,然后进一步修改。

Google的销售人员游说到,“你这样左一个文本,右一个文本,不仅不容易找,而且修改过的内容很容易遗漏。用Google Docs,就可以省掉所有这些麻烦。文本放在Google云计算平台上,无论你是在办公室里,还是在家里,你都可以对同一份文本进行修改。而且你可以与你 的同事共享这个文本,让他也可以对同一份文本进行修改。”

我问,“万一我不同意同事的修改怎么办?”

Google的销售人员回答,“没关系,就像wiki一样,所有修改都有记录。如果需要,你可以恢复旧版本。还有,如果你需要查找几年前你写的另一份文 件,你不必记住名字,只要一搜索就可以从故纸堆里找出来。”

于是我心旌动摇,准备建议领导把公司的设计文档全部放到Google Docs里去。这时候,微软的销售人员上门了。“听说你要建议把公司所有机密设计文件,转移到Google Docs中去?不怕Googler偷看呀?”

我说,“Google已经提供了解决方案,给我们所有文件加了密,密钥掌握在我们手里。即便Googler想偷看,他们也看不到。”

微软的销售人员说,“这样就好,安全第一。另外,你们的设计文档格式很简单吗?示意图怎么画,Google Docs有类似于微软Visio那样的工具吗?还有,如果你要比较两份不同的文件有什么差异,Google Docs有没有微软Word那样‘比较与合并’ 等等功能?”

微软反制的着力点在于,Google Docs的所有操作都在浏览器里完成,所有功能都通过JavaScript实现。受制于JavaScript的限制,Google Docs在功能上,不仅目前赶不上Microsoft Office,而且预计在相当长的未来,也不可能与之抗衡。

4.云计算大战,Google出招

两军对垒,通常双方阵线连绵数十公里。在发动进攻的时候,很少出现全线推进的情况。相反,进攻往往出现在有限几个突击口上。集结强大兵力,在几个突击口上猛烈打击,期望在敌方阵线撕开缺口,然后向敌方纵深挺进,分割敌人阵线,再逐个合围,各个击破。

巴巴罗萨战役 Operation Barbarossa

大公司之间竞争也有类似特点,双方都有很多产品和服务,而且功能类似,这就像战争中两军对峙的阵线。当一个公司向对手发动竞争攻势的时候,往往选择少数几个产品,大做广告和其它市场推销活动,以期迅速扩大在相关市场的占有率。这类似于在战争中,选择突破口,集结兵力,发动冲击,企图撕开敌军阵线。

譬如Google Docs,虽说它上线已有相当时日,但是从没有见到Google大规模宣传这个服务。所以Google Docs与Microsoft Office,是对峙的阵线,而不是发动进攻的突击口。

Google在云计算战役中,选择的突破口是什么产品和服务呢?答案,Google gadgets。

Google gadgets

Google gadgets简化了建网站的工作。每个网页可以视作多个元素集成,譬如上面显示的网页包含6个元素,从左上到右下分别是天气,时钟,日 历,YouTube视频,生活小窍门,以及搜索。网页元素,portlet,这个概念早在1999年就已经出现。Google gadgets是portlets的一种实现方式,与其它实现方式相比,Google gadgets的优势是使用方便。

譬如某人想建一个网站,在网站的首页的下方,想插入一个搜索框。他不用担心如何去实现隐藏在页面背后的搜索引擎,他要做的,仅仅是在网页的HTML里,插 入几行JavaScript。这几行JavaScript,不仅在页面上显示了一个搜索框,而且更重要的是把这个网页与Google的云计算平台联系在一 起。每当用户输入搜索请求时,这段JavaScript就把用户的请求,转发给Google搜索引擎,然后接收Google搜索到的结果,并显示在网页 上。

Google gadgets的意义在于,不再像以往的产品那样,在电脑本地获取服务和内容。Google gadgets的服务和内容,来自于Google云计算平台。譬如以往的时钟,显示的时间是由电脑自己演算出来的。如果系统设置错误,时钟就有可能出错。 但是Google gadget的时钟,它的时间不是电脑本地演算的,而是从Google云计算平台索取的。只要Google云计算平台不出错,只要网络链接正常,即便电脑 本身的设置出了问题,Google gadget时钟也照样准确。

Google gadgets不仅可以给建网站的人提供便利,基于同样原理,Google又推出了Google desktop gadgets。它给千千万万普通的电脑使用者,带来多样化的,时尚的服务。

Google desktop gadgets

有人说,Google gadgets让电脑弱智。因为一旦Google gadgets大行其道,电脑就无需强大的CPU和存储空间,它所需要的无非是浏览器,接收用户的请求,转发给Google云计算平台,云计算平台提供内 容和服务,然后浏览器接收这些来自云计算平台的内容和服务结果,并且把它们显示给用户。

其实,企图让电脑弱智的,不仅仅是Google云计算,早在1996年,Oracle总裁Larry Ellison就提出过网络电脑(Network computer)的构想。网络电脑的功能,仅限于浏览器,而内容和服务来自于网络服务器端。与Google云计算平台不同的是,Larry的构想是,网 络服务器端最好是Oracle的数据库以及Oracle的应用服务器。

十多年过去了,Larry的构想没有成为现实,原因有三,

  1. Network computer的卖点是便宜,因为与传统PC相比,NC无需昂贵的CPU,内存和硬盘。但是近十年来,PC的价格迅速下跌,NC的卖点失去了吸引力。
  2. Larry Ellison设想的,以Oracle Database为核心的网络服务器,没有提供很好的可扩展性,也没有提供大量的有吸引力的应用。
  3. 网络带宽的发展,没有超过PC计算能力的发展。

十年后的今日,以Google云计算平台为代表的网络服务器集群,比Oracle Database有了长足的改进。不仅可扩展性更好,而且Google提供了很多能吸引人的服务,譬如搜索,视频(YouTube),地图等等。

同时,虽然网络带宽的发展没有超越PC计算能力的发展,但是至少在很多地区,网络带宽不再是制约网络服务发展的瓶颈。

Network computer失败的三条原因中,两条发生了变化,所以,Google拾起老概念,换上新包装,向微软发起攻势。其战略目标,无非是弱化PC本地计算能 力的重要性,增强对Google云计算平台的依赖性。

下一步Google gadgets的发展方向是什么?

请注意,目前绝大多数gadgets都是单向使用Google云计算平台所提供的内容和服务,而缺少促进用户上传新的内容和新的服务的gadgets。

所以,不妨大胆预测一下,Google下一步将非常热衷推出像论坛(forum),维基网页(wikipage)这样的gadgets。通过它们,促进用户给Google云计算平台上传用户生成的数据。

进一步,Google将投入巨大资源,发展AppEngine。AppEngine的用处是方便用户开发新的服务逻辑,并且在云计算平台上运行这些新的服 务。但是AppEngine的开发,势必遇到很多技术上的困难。详细分析,我们留给下一篇来讨论。

5.是云计算,还是云存储?

Gadgets的目标是方便大家建网站。但是单靠gadgets,建网站的工作还是不够方便。

通常网站有三个组成部分,1. 网页,2. 业务逻辑, 3. 数据存储。如果说网页相当于商店,那么业务逻辑相当于车间,而数据存储相当于仓库。商店,车间和仓库三者中,技术含量最高的,当属车间。

Manufacture in old time

车间管理可以大致概括为两件事,

1. 工艺流程,

2. 资源调度。工艺流程关心的是,先做什么,后做什么,才能生产一个完整的产品。资源调度的问题是,哪个工人,用哪台机器,在哪个时间,做什么。

网站的业务逻辑处理,大致来说也分业务流程和资源调度两部分。

流程的设计,每个网站不尽相同。譬如有两个网站,一个招聘人才,另一个销售图书,它们的业务流程非常不一样。但是销售图书的网站,与销售电器的网站,它们 两者的业务流程相对比较接近。

流程设计千变万化,而资源调度却有章可循。所谓计算机资源,无非是这五种东西,

  1. CPU,
  2. RAM,
  3. Disk,
  4. RAM-Disk IO,
  5. Network。资源调度,无非是优化使用这五种资源,使之在最短的时间内,完成分配来的工作。

优化使用这五种资源,目标挺明确,实施起来却相当不容易。一日偶遇一仙人,谈到计算资源调度优化的问题,仙人说,他有一套五行八卦的优化办法,用中国古代 智慧,解决当今科技难题。我把仙人的办法概括为以下几个要点,

  1. 五行相生相克,系统优化不能偏执单一资源的优化。
  2. 系统的总体效率需要一个测度,这个测度被称为“阴阳度”。
  3. 阴阳度不是五种资源的简单加权和。阴阳度与五行的关系是非线性的,这种非线性关系可以参照河图洛书来确定,譬如规定五行中土的阴阳度为0,河图数零点的阴 阳度为-5,洛书数零点的阴阳度为-10。
  4. 时刻监控系统总体的阴阳度,阴阳度变化的正常模式可以分为太极,太虚以及太一三种。
  5. 当阴阳度的变化偏离了正常的模式,就需要对系统进行调整。调整的办法参见“说卦”中的六种范式,即洛书逆式,先天八卦,后天八卦,神也者,洛书顺式,和乾 坤六子。

仙人的办法听上去很有美感,但是操作起来却有难度。正在困惑之时,听到Google宣布,“我有办法解决资源调度问题,你们只须专注于业务流程”,确实为 之感召。

Google的解决办法,是AppEngine。

Google AppEngine logo

问题是,Google AppEngine真得能够优化任何业务流程的资源调度吗?

譬如有人想建一个人才招聘网站,招聘的业务流程如下图所示。Google打算劝说这个人把网站建在Google云计算平台上,做为技术支 持,AppEngine应该提供哪些功能?

Recruiting process business logic

猛一看,觉得很容易,流程清楚,算法简单。只需要把流程中诸多环节,归并成几个模块,即大功告成。

再看看,事情没那么简单。整个流程不是从头到尾一次走完,譬如interview会有好几次,然后过几天才会发offer。所以,应当把整个流程的每个模 块独立出来,封装成服务,每个服务能够独立运行。召之即来,来之能战。平时不用,不占资源。

SOA(Service Oriented Architecture)还有一个好处,是便于重组业务流程。譬如系统上线以后,发现在面试(interview)以前,还需要添加一个电话约谈 (phone screen)的环节。如果流程中每个服务都能独立运行,添加新的服务就很容易,不至于造成牵一发动全身的局面。

SOA的结构设计,有很多优点,但是仍然有遗留问题。如果同时有很多人使用这个招聘网,系统的吞吐量需要随之加大,怎么办?增加系统吞吐量的办法,有两条思路。

第一种办法是购置多台机器,每台机器上安装所有服务。当很多人同时使用招聘网的时候,把他们的需求均匀转发到各个机器上去,这样每台机器的负载都不大,但 是整个系统的吞吐量增加。

第二种办法的效率更高,它可以用数量较少的机器,达到和第一种办法相同的吞吐量。或者,用相同数量的机器,在更短的时间内完成所有任务。这种办法首先分析 每个服务耗费的资源,譬如CPU时间和RAM空间等等。然后给资源耗费量大的服务多分配几台机器,以免它们成为整个业务流程的瓶颈。

第二种办法虽然有很多好处,但是实现起来有些难处。首先是如何监控和分析每个服务的资源消耗,其次是如何自动把服务从一台机器转移到另一台机器去运行。

或许有人会问,为什么不提多线程的办法呢?所谓多线程是把多个任务交给多个线程去完成,这些线程交叉使用CPU,IO,Disk等等资源,减少使用这些资 源前的排队时间。多线程的办法,关注的是每个服务的实现细节。而我们刚才讨论的,是服务与服务之间怎么整合的问题,所以,是不同层面的问题。

又有人问,为什么不提MapReduce之类并行处理的办法?与多线程一样,MapReduce关注的是每个服务的实现细节,是不同层面的问题。

回到前面的问题,如果Google打算劝说大家把网站建在Google云计算平台上,做为技术支持,AppEngine应该提供哪些功能?

  1. 开放更底层的APIs,而不仅仅是Python的APIs。便于第三方开发人员,实现逻辑复杂,以及资源使用方式复杂的模块。
  2. 提供IDE,方便第三方开发人员,把模块封装成符合Google云计算平台规范的服务。
  3. 开发调度工具,用于监督各个服务资源消耗,分配合适的机器去负责各个服务运行等等。
  4. 开发预警和修复工具。开放自己的平台,去运行第三方人员(外人)开发的服务。对于Google来讲,有理由提高戒备,预防云计算平台崩溃,万一崩溃了,能 够迅速修复。

这四个功能,AppEngine目前都没有实现,所以云计算平台,对于第三方开发人员来说,暂时不是计算平台,而是存储平台。

6.安全性的难题,有解还是无解?

对于Google来说,如果希望AppEngine能够获得商业上的巨大成功,吸引更多用户,尤其是企业用户,最大的挑战在于,如何保障客户的数据和私有程序的安全。

举个例子,譬如Google想劝说某家银行,用不着银行自己建数据中心,把银行的数据存到Google的云计算平台,每月给Google一笔数据托管费即可。银行很可能会问两个问题,

  1. 如何防范Google员工偷窥银行的数据?
  2. 银行有投资业务,所以银行自己开发了一套软件,用于评估投资风险和收益。如何防范Google员工偷窥这些软件的代码?

Google当然会派律师去游说,指天画地地发毒誓,说如果出现Google偷窥数据及代码的情况,根据双方合同,Google必将受到法律严惩,等等。

但是银行还是不放心,作案取证本来就麻烦,如果Google再做点手脚遮掩,很可能查无实据。即便能找到实据,一个案子办下来,时间也得拖很长。

这个问题,困扰的不是Google一家,而是所有负责数据托管的公司面临的共同问题。所以,现在只有两类公司,敢把数据托管给他人。一种是中小企业,他们 或许会觉得自己在竞争对手眼里不那么重要,对手不至于甘冒风险去刺探自己的机密。另一种是数据本身机密性不高的公司,譬如新浪网,天涯社区等等,他们的数 据内容本来就是公开的。

所以,如果Google打算吸引重量级企业用户来使用云计算平台,最好的办法是从技术上想出路,保证做到,即便Google挖空心思想偷窥,也看不到。

1. 有人问,为何不用VPN技术呢?

VPN(Virtual Private Network)虚拟私网,解决的是在如何通过公共网络,远程访问企业内部私网的问题,譬如在家处理公司业务,需要把自家的电脑,通过公共网络,接入到公司内部网络中去。所以,VPN解决的问题主要在于,保证家里电脑和公司电脑传输数据时,数据通过公网时的安全。

经常在北京街头看到振远护卫的押运车,以及持枪的押运员,负责运输现钞,有人戏称他们是振远镖局。镖局的任务之一是,把现钞从银行押运到各个ATM自动取钱机,中途通过公共马路。现钞安全到达目的地,镖局的任务圆满完成。但是,如果有谁把ATM取钱机撬开了,镖局不负责任。

类似的道理,客户可以通过VPN把数据安全地传输到Google云计算平台,但是VPN不能阻止Google的内部员工偷窥存放在Google机器上的数据。

振远护卫在奥运会期间负责押运运动员尿样

2. 还有人建议,可以给数据加密。

客户在上传数据到Google云计算平台前,先用私钥(private key)给数据加密,这样存储在Google云计算平台的数据,是加了密的数据。Google员工即便打开了文件,看到的也不过是一堆乱码。当客户授权给 他的同事看数据时,给同事一份公钥(public key)。同事用这个公钥解码,然后就能读到真实的内容了。

德国人的钥匙很有意思,办公室的钥匙,同时可以打开大楼的门,以及公司的门,但是不能打开隔壁办公室的门。隔壁办公室的钥匙,也可以打开大楼的门,以及公 司的门。所以,德国人的钥匙和锁,是有层次的。

公钥也可以这么设计,一个部门的公钥,不仅可以解密本部门的文件,而且可以解密公司内部公开的文件,但是不能解密其它部门的文件。实现这样有层次的公钥并 不难,一个简单的办法是把整个公钥分成几段,第一段负责公司内部公开的文件,第二段负责某特定部门的文件等等。

这个办法猛一听起来似乎可行,但是仔细想想却不然。它有四个缺陷,a. 不能给程序加密,b. 不能搜索加了密的数据,c. 不能给数据库文件加密,d. 公司员工离职后,有可能会造成私钥和公钥的外泄。

3. 程序如何加密。

按照前一段的思路,平时给程序加密,只有当运行程序前,才解密。程序运行结束后,再度加密,同时销毁解密了的程序。但是这个办法不可行。

解密和加密,是相当耗用CPU的,同时占用时间也比较长。如果实施平时加密,用时解密的措施,用户等待时间会相当长。更严重的是,通常一段程序不能解决所有问题,一段程序往往会调用其它程序,其它程序又调用另外程序。如果平时把所有程序加密,用时再逐个解密,整个流程将占用很长时间,这将严重影响用户的体 验。

现实中通行的办法是给程序变形,学名叫Obfuscation。道理很简单,把程序中的变量名称转换掉,同时切割整个程序,并且重新排序,以便混淆耳目。 变了型的程序依然可以运行。

正常的编译过程,是把人类可读的源代码(譬如用Java写的程序),翻译成机器代码(譬如Java bytecode)。而反编译是把机器代码,逆向翻译成人类可读的源代码。虽然Obfuscation不能从根本上阻止反编译,但是却增加了这个工作的难 度。

虽然有难度,但是重赏之下必有勇夫。譬如,如果能盗窃银行密码,肯定会有人不辞劳苦地反编译。

4. 加密与搜索。

“Greatness is never a given, it must be earned”,这句话怎么翻译?在Google或者百度里搜一搜这句话,一定会发现这是奥巴马总统就职演说中的一句。有人翻译成,“伟大不是凭空而来 的,而是赢得的”。意思当然不错,但是觉得不如原句有气势,不如翻译成,“坐等等不来伟大,伟大必定来自于努力”。

Google和百度是如何搜索到这话出自奥巴马的演讲呢?道理说穿了并不复杂。

首先,Google和百度建一个索引,学名叫倒排索引(inverted index)。倒排索引中记录了每个单词出现在哪些文章中,而且记录了在这些文章中的什么位置出现过。

其次,当用户搜索“Greatness is never a given”,搜索引擎通过倒排索引,查找“greatness”在哪些文章中出现过,查找“never”在哪些文章中出现过,等等。然后把众多的搜索结 果合并起来,看看哪些文章中不仅出现过“greatness”,还出现过“never”,“given”等等。

如果把奥巴马原文加了密,不仅每个词都变成了乱码,而且词与词之间的空格消失了,甚至连词序也可能被打乱。这样一来,就没有办法按照通常的做法构建倒排索 引。

怎么办?思路有三条。

a. 把加密算法和构建倒排索引的算法通盘考虑,重新设计一套一体化的算法。

这个思路能够一揽子解决我们面临的所有问题,但是设计这套算法的难度很高。目前还没有人能够想出有效的算法。

b. 客户自己动手建倒排索引,然后把索引加密,上传到云计算平台。

但是构建倒排索引是一件计算量很大的工作,如果客户能够自己构建倒排索引,那么就没有必要使用云计算平台。理由是,云计算平台的卖点是方便客户处理繁重的数据计算。如果云计算平台不能帮助客户构建他们专用的倒排索引,那么云计算的卖点就大大失色。

更严重的问题是,在使用索引的时候,必须先解密。如果解密了的索引被Google员工偷看了,那么加密就失去意义了。原因是,索引中透露了正文中出现过那 些词,以及这些词出现的位置。通过索引中的这些信息,可以复制原文的。即便不能一字不漏的全文复制,也能复制得八九不离十。

所以,这个思路不可行。

c. 在云计算平台中分离出一部份作为密室,专供企业用户存放保密级别很高的数据,以及运行保密级别很高的程序。

信息安全的法则是分离分离再分离。给每个企业用户分配一部份机器作为密室。这些机器的Root权限掌握在企业用户手里。Google的员工只能监控密室中 的机器的CPU,RAM和IO的使用情况,但是他们没有权限进入机器,查看文件,运行程序。

这个办法虽然技术含量不高,但是比较容易实现。缺点是容易造成资源浪费。因为如果给每个客户单独开密室,即使密室里的机器空闲,别人也没法用。

5. 加密与数据库。

数据库最多只能对字段逐个加密,譬如“greatness”变成“@#¥%”。但是不能整句整段地加密,否则数据库的索引,B+ tree,就没法构建。

所以,对数据库的系统管理员,无法实施高级别的加密。

6. 私钥和公钥的外泄。

公司员工离职后,很可能复制一份公司的公钥和在职期间自己使用的私钥带走。如果沿用前面所述,用私钥加密,用公钥解密的办法,员工离开公司后,仍然能阅读 公司的文件,甚至篡改当年自己在职期间起草的文件。

所以,最妥善的办法是不让员工直接接触公司密钥。从这个原则出发,作者也好,读者也好,都没有密钥。作者要加密,读者要解密,让他们把文件发给密钥中心, 由密钥中心统一负责加密和解密。

另外,即便由密钥中心负责保管密钥,如果长期使用同一套密钥,还是不安全。所以,密钥中心定期更换密钥,分批给文件重新加密。

这个办法可行,但是比较笨拙,因为,a. 密钥中心成为瓶颈,b. 给旧文件重新加密是负担很重的工作。

Durer’s grid

前面花了相当长的篇幅讨论各种为托管的数据和程序加密的办法,结论是,现有技术无法保障被托管的数据和程序被偷窥。

为Google计,目前能做的,似乎是明确云计算的定位。

1. 锁定目标客户,这些客户有一个共性,就是对内容和程序的安全性不敏感。

比如各种门户网站,论坛,B2C网上商店,政务和各种公共事业的网站,以及中小型企业等等。这部分用户数量不少,市场相当广阔。

2. 提供特色服务,尤其是海量数据处理。

云计算平台类似于巨型计算机。客户利用云计算平台,处理自己的计算中心很难完成的海量数据处理。例如:电脑动画制作,天气预报等等。

3. 根据不同的保密等级,做分级处理。

实际上一个企业的重要秘密信息是不多的,机密文件存放在企业自己的机房里。其它不需要保密的文件,托管到云计算平台。这个市场也是很大的。

7.天上究竟会有几朵云?

上一章长篇大论地讨论,云计算是否能够提供有效的加密措施,保障客户的内容以及程序,不被云计算平台的拥有者偷窥。

我们的结论是悲观的。

既然云计算平台无法提供有效的加密措施,那么云计算平台只能吸引那些对于自己的内容和程序的保密不那么敏感的企业。

但是大型企业,包括银行和电信,它们对云计算能够提供的超大规模存储能力,以及超大规模并行数据处理的能力,有天然的需求。

怎么办?

现实的解决办法是帮助大型企业建设属于它们自己的云计算平台。

换而言之,未来的天空中,将漂浮着Google和Microsoft几朵云,这是几朵大云。在大云的周围,散落着一些小云。

如何构建云计算平台?

说来也不很神秘。云计算平台的基本思想,可以简单概括为,设计一套操作系统,同时管理多台电脑,尤其是把多台电脑结合起来,当一台超级电脑使用。

想深入了解云计算技术,以下论文是不能不看的。

1. Google File System: http://research.google.com/archive/gfs-sosp2003.pdf

把多个电脑的硬盘组合起来,形成一个超大规模的硬盘,用来存储海量数据,同时保障万一有某些硬盘崩溃了,不至于遗祸整个系统。

2. MapReduce: http://labs.google.com/papers/mapreduce-osdi04.pdf

如何实现并行计算。道理很简单,但是用好却不容易。下面两篇论文,可以作为范例,指导如何正确使用MapReduce。

2.1. Large Language Models in Machine Translation

http://acl.ldc.upenn.edu/D/D07/D07-1090.pdf

2.2. Parallelizing Support Vector Machines on Distributed Computers

http://books.nips.cc/papers/files/nips20/NIPS2007_0435.pdf

3. Chubby lock service: http://research.google.com/archive/chubby-osdi06.pdf

电脑操作经常要用到锁机制,譬如用锁防止两个进程同时向同一个文件写数据。这篇论文谈的是,在由多台电脑组成的分布式系统中,集中管理锁的机制。

4. BigTable: http://research.google.com/archive/bigtable-osdi06.pdf

这篇文章既是讲如何实现分布式数据库,同时也可以把它看成范例,如何正确使用Chubby锁机制,和GFS文件系统。

5. The Google cluster architecture: http://www.computer.org/micro/mi2003/m2022.pdf

各个组成部分完成以后,如何组建一个计算中心。这是这篇文章的主题。

Google式云计算平台有两大特色,

1. 便宜。即使用几台穷人买得起的烂PC,也能构建一个麻雀虽小但是五脏俱全的Google式云计算平台。其实,Google自己就是这么起家的。

2. 稳定。便宜的机器经常死机。Google式云计算平台,能保证一部份机器死机不会造成整个系统的崩溃。

A cluster consisting of many cheap PCs

以前CMU有个教授,说过这么一段话,大意是:遇到一篇以前没有读过的论文,最好先蹲在厕所里翻翻。很多论文无病呻吟,或者装神弄鬼。对待这样的论文,处 理的办法是立刻冲掉。不幸的是,大多数论文都可以这样处理。

后来,这段话被记者捅了出去。系主任不得以,不仅公开道歉,而且内部通报批评该教授,不该说这种politically incorrect的话。但是暗地里,很多师生都非常认同教授的看法。

前面几篇文章,不仅不能被冲掉,而且值得反复读,再三读。读完这些论文,你一定会对这两个人感到亲切,Jeffrey Dean和Sanjay Ghemawat。

如果说Google的两位创始人Larry Page和Sergey Brin确定了Google搜索引擎的算法和数据结构,那么奠定了Google后台的集群系统,也就是我们今天耳熟能详的Google云计算平台,就是 Jeffrey Dean 和Sanjay Ghemawat这两位。

Jeffrey Dean, Ph.D

Sanjay Ghemawat, Ph.D

但是,只读这么几篇论文是不是就足够了呢?

No!

对比一下传统的单机的操作系统,如果把GFS理解为云计算版的文件系统,把MapReduce理解为云计算版的进程管理,把Chubby理解为云计算版的 synchronization。

缺了什么?

1. Memory management。2. Scheduling。

为什么不列举这两个方面的论文,方便大家阅读?

因为Google没有发表。或许是Google把这两个方面的技术,视为Google云计算的核心机密,所以才没有发表论文公开介绍。

读完论文后,想构建一个云计算平台,是不是必须写程序,从头实现?

No!

Hadoop是一个开源项目,把前面提到的几个Google式云计算技术,用Java实现了。

我们不妨站在Hadoop台阶上,把未尽的事业推向前进。

前进方向,

1. Memory management。2. Scheduling。

8.云中说禅

云计算是一个大买卖,各大公司不会眼睁睁看着Google吃独食。IBM,Yahoo,Amazon,Microsoft等等相继跟进,都在宣传自己的云计算方案。

Google致力于云计算研究与实践,已经有十年了,技术积累厚实,说话底气足。其它公司嚷嚷归嚷嚷,总得拿出点真材实料,否则靠什么争取客户?从头开始 研究开发当然是来不及了,于是IBM也好,Yahoo也好,Amazon也好,纷纷借Open Source的Hadoop,作为自己切入云计算市场的基石。

看一看IBM的Blue Cloud方案,以及Amazon的EC2方案,除了Hadoop以外,它们还用到了另一个开源软件,Xen。Xen是Zen的异体词,Zen的意思是禅。

计算机技术和禅有什么关系?

看看Lucent公司的Logo。第一次见到这个logo的时候,不解。请教老美,老美很吃惊,说,“这是禅啊,你们东方的东西。”

这个用毛笔画出来的圆圈,英文名字叫Enso。这个符号来自日本,通常被当作禅的标记。凭心而论,日本在世界范围内弘扬东方文化,是做了很大贡献的。譬如西方人对禅的了解,主要来自于日本的推介。

Lucent Logo

1974年,美国出版了一本名字很古怪的书,“禅与摩托车维护的艺术:对价值的探求(Zen and the Art of Motorcycle Maintenance:An Inquiry into Value)”。这本书的主线是一伙人骑摩托,17天环游美国的游记,其中穿插了大量的哲学讨论。此书出版后,受到极大欢迎。

2003年,剑桥大学计算技术实验室的几个人在合写一篇论文,文章写得差不多了,但是还缺一个标题。其中一位开玩笑地建议到,“要么就叫Zen and the Art of CPU Cycle Maintenance吧”。众人大悦。

最后论文定名为“Xen and the Art of Virtualization”。同时,把整个项目定名为Xen。

Xen是做什么的?

用一句话来概括,Xen的目标,是如何在一台计算机的硬件上,同时运行多个OS。什么情况下需要在同一台计算机上同时运行多个OS?

举个例子,现在电脑病毒日益猖獗。纵然有卡巴斯基等等解药,但是道高一尺魔高一丈,病毒屡禁不止,而且毒性越来越烈,常常危及整个OS。

有人出了一个主意,在同一台电脑的硬件上,同时运行多个OS,把一些基本的应用放在一个OS上,其它的应用留在其它OS上。用户切换OS的方式,犹如切换窗口一样。如果一些应用染上了病毒,最多把该应用所在的OS重装,而不至于影响其它OS,尤其是不必担心硬盘上重要的文件遭到破坏。

为什么Xen与云计算有关?

在云计算平台上运行的程序,来自不同的客户。不能保证这些客户程序没有bugs,也不能杜绝恶意的破坏性程序。如何保证一个客户的程序,不至于破坏其它客 户的程序运行,不至于损坏其它客户的文件?

最简单的办法是给不同的客户分配不同的机器,井水不犯河水。但是这样的做法不能高效率地使用资源。美国客户的高峰时段,恰巧是中国客户的夜间休息时段。如 果分别给美国中国客户分配不同机器,美国高峰时段,美国客户的机器忙不过来,而中国客户的机器却在闲置。

所以最理想的做法,是让不同客户共享计算机硬件,但是各自拥有各自的OS。这样,既高效地使用硬件资源,又保证井水不犯河水。

举个例子,假设后台有两个功能,F1,F2。如果现在各自有个machine farms,MF1和MF2。MF1的每台机器只运行F1,而MF2的机器只运行F2。即便在系统里装了LoadBalancer,F1的请求只能发到 MF1的某一台机器上去。但是如果MF1里面所有机器都忙不开了呢?在这种情况下,LoadBalancer也没办法。

怎么办?把MF1和MF2合并,每台机器上即运行F1,也运行F2。

但是如果F1有bugs,导致死机,会不会影响到F2?当然会。怎么办?

用virtualization技术,在同一台机器的硬件上,同时运行两套OSes,OS1里面只跑F1,OS2里面只跑F2。F1的bug,导致OS1 崩溃,但是不会影响OS2里的F2。

Xen提供了实现这一目标的技术解决方案。当然,在一台计算机上支持多个OS,是有代价的。Xen消耗了一部份CPU时间,但是这个额外代价只有3%到7 %。

如果F1是Oracle,F2是DB2等等之类heavy duty applications,当然给它们分配专用机器最合适。但是如果F1和F2不是那么heavy duty,而且负载分布交错,也就是你忙我不忙的情况经常发生,那么把F1和F2放置在同一台机器上,用virtualization技术相互隔离,以保 证互不干扰,就有价值了。

Virtualization的价值在于减少服务器的数量。在前面的例子中,如果F1和F2各自有自己的machine farms,两个farms里面的机器数量分别是MF1和MF2,那么合并起来以后,统一的machine farm里的机器数量比MF1+MF2少。

所以,借着云计算的东风,Xen大热。

The structure of a machine running the Xen, hosting a number of different guest OSes.

上图描述的是Xen的体系结构。最底层的是计算机硬件,包括CPU,RAM,硬盘接口,网卡,外设数据总线等等。

硬件层之上,是Xen hypervisor层,包括总控界面(Xen Control Interface),虚拟CPU,虚拟RAM,虚拟硬盘,虚拟网卡等等。

在Xen层之上,是各个OS实例(OS instances)。其中最左边的OS实例很特别。在启动Xen的时候,最左边的OS实例,Domain0 on XenoLinux,自动被启动。Domain0里运行着Xen Control Software,这个软件控制着各个OS实例的启动,终止,以及监控其运行情况。

Domain0对于其它OS实例的控制,是通过Xen层中Xen Control Interface来实现的。而这个Xen Control Interface只对Domain0开放。其它OS实例只有被管理的义务,而没有管理其它实例的权力。

每个OS实例都被分配一套虚拟的CPU,RAM,硬盘和网卡。每个OS实例使用这些虚拟的设备,与通常的OS并无不同。

多个OS实例共享CPU的实现,是通过两套机制来完成。当多个OS实例请求使用CPU,这些请求被放置在hypercall队列里。Xen hypervisor根据预先设定的优先级政策,在hypercall队列里挑选出下一个被执行的请求。请求被处理完了以后,Xen通过异步的事件响应机 制(async event-callback handler),把结果反馈给相应的OS实例。所谓虚拟CPU,说白了就是这两套机制的interface APIs。

在启动一个新的OS实例的时候,Domain0会给它分配一部份RAM。如果实际运行中,需要更多的RAM,Domain0会增加这个OS实例的配额,直 至最高上限。各个OS实例都有自己的RAM区域,彼此不相互干扰。从每个OS实例的眼中看,似乎自己的RAM区域在物理上位于相邻区域。但是事实上不是这 样。这种善意的欺骗归功于虚拟RAM。虚拟RAM不仅记录着物理RAM的分配和使用,而且负责地址的翻译等等工作。

至于Disk IO和Network IO的读写请求,被放置在一个环状队列中,通过Consumer-Producer锁机制进行异步操作。

每个OS实例配备着一个虚拟硬盘,这个虚拟硬盘记录着每个OS实例所占用的物理硬盘的空间。每个OS实例只能看到分配给自己的硬盘空间,而不能看到其它 OS实例的硬盘里的文件。而Domain0是例外,它能够看到整个硬盘系统中所有文件。

Xen的详细描述和分析,可以读前面提到的那篇论文,“Xen and the Art of Virtualization”,

Xen开源软件的下载,可以去Xen网站寻找。

VMWare infrastructure

Xen并不是横空出世的新创意。计算机界往往出现工业界领先于学术界的局面,Virtualization技术就是这样一个例子。早在1998年,硅谷 Palo Alto出现了一家公司,最早实现了多个OS共享一台计算机的设想。这家公司的名字叫VMWare,现在卖给了EMC。

Xen与VMWare在技术上有很大相似之处。从Xen的论文看,Xen的技术似乎比VMWare有更多优势。但是从产品系列的完整,以及多年来的实际运 行经验来看,VMWare似乎能够提供用户更可靠的稳定性和售后服务。

9.赚钱才是硬道理

本系列开篇时说到,Google开放云计算平台的目的是为了赚钱。接下去我们分析了云计算的功能以及技术实现。

现在终点回到起点,在我们了解了云计算的功能和技术以后,最后的问题是如何借用云计算平台赚钱?

黄兄推荐了一篇参考文献,题目是“Cloud computing with Linux”(http://www.ibm.com/developerworks/linux/library/l-cloud-computing /index.html)。这个题目有点推销Linux的倾向,但是仔细看正文,发现这是一篇好文章。好在三个方面,

  1. 它把云计算能够提供的服务分成了4类。各个服务层面针对需求不同的目标客户群。
  2. 在这4类服务内,列举了各个参与竞争的公司。战场的形势一目了然。
  3. 如果你想参与云计算,从中获利。仔细琢磨这篇文章,你将对自己的产品的定位有一个比较清晰的理解。

Cloud computing layers

这篇文章把云计算的目标客户分成四类。从最底层说起,

1. Data-storage-as-a-Service(dSaas),说白了就是把云计算包装成一个巨大的网盘,客户想保存什么文件,不论是什么格式的, 统统可以上传到这个网盘里。

云计算的网盘有一个优势,是PC的硬盘无法媲美的。譬如,你在办公室里写了一个文件,晚上回家想接着写。文件存放在办公室的PC里,想调用这个文件,你先 得设置VPN,才能访问你办公室的PC,比较麻烦。如果你下班前,把文件上传到云计算的网盘里,你回家后想调用这份文件就容易得多。

如果把云计算和房地产开发相比较。盖了一栋空房子,没有装修,也没有通电通水通气,如何赚钱?最简单的办法是把空房子出租,给客户做仓库用。网盘就相当于 仓库。

2. Infrastructure-as-a-Service(IaaS),是指提供计算能力,就像提供标准厂房,供电供水供气。

客户租用标准厂房,是为了组装一个生产车间。所以,客户光租了标准厂房还不够,他们还得自己动手,购置机器,雇用工人。

把云计算包装成IaaS,目标客户是动画制作商,数据挖掘商,天气预报局等等。他们编写自己的程序,自己负责运行和分析结果。之所以借助云计算IaaS服 务,主要是借重云计算的平行计算的能力。

把云计算IaaS与标准厂房做个逐项类比,云计算的IaaS类似于标准厂房,天气预报局编写的程序就像是客户购置的机器,天气预报分析师就像是车间里的工 人。

3. Platform-as-a-Service (PaaS)。类似于开发商盖了一栋商厦,里面分割成很多摊位,把摊位出租给各个小摊贩,卖衣服鞋帽等等。

PaaS针对的客户是各种传统行业的服务提供商,他们想建一个网站,开设网络商店,但是他们不太了解IT技术,他们开设网络商店所需要做的,基本上只是上 传内容。

4. Software-as-a-Service (SaaS)。类似于开发商不仅建了房子,而且装修成酒店,聘用了酒店管理人员。

酒店面向是两类客户,1. 最终消费者,他们来酒店吃饭和住宿。2. 服务提供商,譬如婚庆代理公司,他们租用餐厅和客房,为新婚者承办婚宴。又譬如会议承办机构,他们利用酒店的会议室等等设施,代办各种会议。

SaaS也一样,它可以给企业提供ERP之类的服务,也可以给其它网站提供Gadgets,譬如地图指南,或者日历等等。

Amazon Web Service bandwidth

云计算的商务做得最好的,当属Amazon.com。

Amazon发轫于网络书店,后来业务扩展到卖电子产品,甚至服装,玩具,家具以及食品等等。再后来,Amazon不满足于零售业,而是想着开商厦,吸引 各色摊贩借用Amazon的平台,营销各自的产品和提供各自的服务,而Amazon坐收摊位费。

尝到甜头后,Amazon干脆进军房地产,构建自己的云计算平台,提供相应的基础服务,犹如供电供水供气。所谓基础服务,严格定义不容易,但是举几个例子 反而容易理解。

1. 系统整合类,
Amazon Simple Queue Service (SQS),负责数据信息的交互。
Amazon Mechanical Turk (Mturk),负责工作流程的组织。
Amazon Flexible Payments Service (FPS),小额支付服务。
Amazon DevPay,记账和会计服务。
Amazon AWS,客户身份认证服务。

2. 统计类,
Alexa Web Services,流量分析。
Amazon Historical Pricing,查看历史记录。
AWS Management Console (AWS Console),监控客户租用的计算资源的使用情况。

再来看看Google的情况。

Google的抱负很大,dSaaS,IaaS,PaaS和SaaS,各个市场层面,它都想参与。但是奇怪的是,最容易做的网盘,即dSaaS业 务,Google没有开展。IaaS不容易找到客户,暂时也无可奈何。针对PaaS,也就是针对想建网站的那一批客户,Google的对策是 AppEngine,但是受限于AppEngine本身的不完善,目前似乎也没有吸引太多客户。Google做得最好的,是SaaS。不仅有 Gmail,Google Docs,还有Maps,Picasa,YouTube,Orkut,Reader等等。

最后谈谈Microsoft的情况。

Microsoft的决心也很大。像Amazon,Yahoo,IBM等等企业,都在借用开源项目,如Hadoop,Xen等等,迅速构建自己的云计算平 台,尽早占领市场。而Microsoft的战略是不用开源项目,从头构建自己的云计算平台,Azure。

Microsoft把自己的云称作“云端”。这个“端”字很有意思,强调的是Microsoft不仅有网络端的云计算平台,而且这个平台与各种 Window OSes,以及Window OSes上各种终端产品紧密结合,形成大纵深的终端产品。

什么叫大纵深的终端产品?

Sina Music Box

拿新浪的音乐盒做个例子。它不仅仅是一个简单的MP3播放器,而且用户可以搜索音乐,音乐盒也可以根据用户以前听过的音乐,推荐音乐,用户还可以组建自己 的专辑,在播放MP3的时候,音乐盒还搜索相应的歌词,配合着播放的节奏,滚动地显示歌词。

也就是说,用户电脑上显示的是终端播放器,但是提供搜索,推荐,专辑和歌词等等的各项功能,依托的是网络端的云计算平台。

如果Microsoft想大力拓展“云端”服务,或许新浪的音乐盒是一个很好的启发。

10.云计算的社会意义

有人说云计算是了无新意的商业噱头,有人说云计算开创了计算技术新时代。

依我的浅见,云计算的技术亮点在于,把一堆廉价PCs捆绑在一起,统一管理,使用起来如同一台超级大型机(Mainframe)一样。

与大型机相比,云计算平台不仅价格便宜,稳定性不差,而且便于不断扩张其计算能力和存储空间。

云计算的社会意义在于,

1. 让社会普遍获得超大规模的数据处理和存储能力。而过去,只有少数机构拥有这些能力。

譬如,客户可以无限量地在网上存放文章,照片和视频等等。一个普通动画工作室,可以制作好莱坞水准的动画片。

2. 进一步降低了传统行业使用IT技术的门槛,有利于改进其生产和经营方式。

譬如,小摊贩可以在Amazon平台上开设网络商店。

3. 对于那些已经拥有IT技术的企业来说,或许把数据存储和程序运行外包给云计算平台,以便降低企业的IT开支。

前提条件是,1. 如果云计算供应商能够保障客户的数据和程序不被偷窥,包括云计算供应商自己,即便想看也看不到客户的数据和程序。2. 网络带宽不会出现拥堵。

对于一部份IT从业人员和DBA,这个前景不一定是美妙。但是社会分工越来越细,这是大势所趋。

4. 形成一个新的IT价值链。

从Data-Storage-as-a-Service(dSaaS),到Infrastructure-as-a-Service(IaaS),到 Platform-as-a-Service(PaaS),到Software-as-a-Service(SaaS),处处是商机。

对于应用开发商来说,传统的终端产品,将向“前店后厂”的模式演化,形成有纵深的产品。

新浪的MusicBox,可以视为大纵深产品的一个雏形。它不仅仅是一个单薄的MP3 Player,而且集搜索,编辑,推荐等等功能为一体。这些功能的实现,依托于“后厂”,也就是依托于产品这个表象的背后,那个云计算平台来实现。

“前店后厂”的产品模式,不仅适合于PC和互联网产品,而且适合于手机业务。下一个系列,我们将讨论如何给手机应用做个“前店”。说得专业些,下一个系列 的题目叫,“移动互联网时代的手机应用架构设计”。

11.赚点钱不容易

一日与一个做销售的朋友聊天,他问,“宗教为什么能吸引信徒?”

不等我回答,他自问自答到,“总结诸多宗教,无非是爱和怕两个字。诱之以爱,锁定之以恐惧。”

“销售也一样,诱之以利,包括功能,服务,减价甚至免费等等。锁定之以损失的恐惧。”

前些天,2009年2月10日,伯克利大学的EECS专业发表了一篇技术报告,题为“云而上,伯克利对云计算的看法(Above the Clouds: A Berkeley View of Cloud Computing)” (http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf)。这篇文章, 得到了Andy Bechtolsheim,John Ousterhout等等学界和商界牛人的支持。

形而上者谓之道,形而下者谓之器。这篇题为“云而上”的文章,虽然出自技术人员之笔,但是通篇讨论的是如何经营云计算。

具体而言,这篇文章主要是站在云计算平台供应商的角度,讨论如何吸引用户。总结一下,文章认为云计算对于用户而言,最大的卖点在于弹性 (elasticity)。

譬如做一个网站,流量难以预料,有时多,有时少,高潮来势汹汹,一阵喧闹过后,又迅速回归平淡。如果支撑网站的是云计算平台,那么无限的资源,需要时可以 迅速集结,无用时可以轻松退还。

最大的卖点在于弹性,这个论点有点出乎意料。云计算能够提供的功能很多,包括超大规模的存储空间,超大规模的计算能力,而且机房规模还有持续壮大的潜力。 为什么该文不强调这些明显的优势,却反复强调云计算的弹性呢?

锁定用户的关键在于唤起他们的恐惧。云计算用户恐惧什么?仍然借用网站的例子来说事儿,

1. 流量猛增时,担心后台计算和存储资源不够,从而失去市场。

2. 流量下跌时,担心后台资源过剩,浪费资金。

文章里举了一个例子,Facebook里面有个制作视频的插件,Animoto,登台亮相之初,宾客盈门,后台服务器在三天内,从50台一下子猛增到 3500台。热闹了一阵子以后,宾客热情消退,门可罗雀,根本用不了3500服务器。

如果Animoto自己建网站,流量大增时,Animoto后台服务器忙不过来,失去的是市场。如果Animoto建了3500台服务器的后台系统,流量大跌以后,这3500台服务器的闲置的后台系统,将造成对现金流的无意义的侵蚀。幸亏Animoto建在Facebook平台之上,而支撑 Facebook平台的,是Joyent,一个云计算平台供应商。云计算,把一场惊悚化为无形。

向潜在的用户推销云计算,该怎么忽悠?We feel your pain, and our cloud is your pain killer。

所以,最大的卖点在于弹性,这个论点猛一看出乎意料之外,但是仔细想想,尽在情理之中。

12.云计算经济学之现金流

云计算技术怎么和经济学扯上关系了?源头在Jim Gray,他于2003年3月写了一篇论文,题为“分布式计算经济学(Distributed Computing Economics)”。

在这篇论文里,他比较分析了计算机硬件价格和网络带宽价格。两者都在逐年下降,但是前者下降的速度比后者的更快。他的结论是,数据处理应该在离数据本身比较近的地方进行,这样有利于降低成本,尤其是网络带宽消费所造成的成本。

如同建火力发电厂,应当把发电厂建在离煤炭矿山近的地方,也就是坑口电厂,更经济实惠。因为传输电力的成本,比运输煤炭的成本要低。

Jim的结论显然不利于云计算市场的开拓。

Jim Gray早年求学于伯克利大学计算机系,毕业后先后任职IBM,DEC,微软,主要致力于数据库研究。1998年获计算机界的诺贝尔奖,图灵奖 (Turing Award)。

2007年的一天,Jim独自驾着自己的游艇,去外海抛撒他母亲的骨灰,后来游艇失踪,Jim再也没有回来。听到这个噩耗后,DigitalGlobal 公司迅速行动起来,在他的航线沿线,拍了几千张卫星照片。另外Amazon免费提供帮助,把这些照片公布在Amazon云计算平台上,号召所有人来帮助寻 找。虽然经过两个月的努力,不幸无果而终。

鉴于Jim Gray在计算机学界和商界享有的盛誉,他反对云计算的观点的影响面也大。所以,伯克利大学这群后生们意识到,欲立必先破,不破则不立。于是,“云而上” 这篇论文花了大量篇幅,谈论云计算经济学,与老学长争锋相对。


Jim Gray,Turing Award laureate,1998
Courtesy http://upload.wikimedia.org/wikipedia/en/7/7e/11-23gray.jpg

云计算经济学的核心,在于规模效应。文章先引用了两个骇人的数字,

1. 企业私有自用的机房,使用效率通常只有5%到20%。

2. 为什么机房使用效率如此低?为什么不减少机房内服务器的数量?因为高峰期对服务器的需求,经常比平均需求高出2到10倍。

云计算平台面向多家企业。各个企业需求计算资源的时间分布不同,这个企业的需求高峰期,可能恰好是另一家企业的需求低潮期。这样,云计算平台可以动态调配 计算资源,既满足高峰时期的需求,又不至于造成低潮期资源的浪费。

就像保险金一样,平时每个投保人都缴纳小额保险费,万一某人有急用时,可以把众人的保险费集中起来,供一人使用。

但是保险公司怎么赚钱?保险公司能否赚钱,取决于如何定价,也就是制订每个投保人需要缴纳的保险费。定价的诀窍在于统计,统计出现意外的概率,统计理赔金 额的分布。

云计算平台供应商赚钱的法门,也在于如何定价。通常情况,价格的制订取决于两方面,

1. 心理。云计算用户能够接受的市场报价。

2. 成本。成本取决于两个因素,a. 云计算平台的规模,b. 购买机房设备的单价。

用户能够接受什么样的云计算使用报价呢?取决于如果该用户使用自己私有机房,需要投入的成本。

这包括,为了满足高峰期的需求,私有机房需要购置的服务器数量,网络带宽消费,电费,房产租金或建设费用,以及机房维护人员的工资。

文章给了一个公式,不等号的左边是使用云计算平台的收益,右边是使用私有机房的收益。注意,关键是右下角那个utilization。如前文所述,效用系 数通常很低,只有5%到20%。低值效用系数造成的后果,是使用私有机房的收益很低。

Cloud pricing

这个公式隐含的意思是,云计算的市场报价,与云计算平台的建设和维护成本,不一定成正比关系。只要云计算平台的报价能够满足左边大于右边,换句话说,只要 云计算的报价能够比用户自建机房更经济实惠,就能吸引用户。

另一方面,如何降低云计算的成本呢?如前所述,一,规划合理的规模,二,降低购买服务器等设备,带宽以及电力的单价。

云计算平台的规模,主要是取决于机房内服务器的数量。建设云计算平台的原则,是以最小的规模,满足高峰期的需求。

如何计算平台的规模呢?“云而上”一文的解决办法是用排队论模型来估算。先估计所有用户的平均需求,以这个平均需求估算需要的服务器数量,然后在这个基数 之上,再增加20%到40%的服务器,作为预备资源,应付特大的需求高峰。

至于购买服务器等设备,带宽以及电力的单价,能降低到什么程度,文章引用了经济学家James Hamilton的调查报告。这份报告,横向比较拥有上万台服务器的超大型计算中心,与拥有数百或者上千量级的中等规模的计算中心,在批量购买服务器,带 宽,电力等等方面的价格优势。

调查的结果是惊人的,超大规模的计算中心在购买设备,带宽和电力时的单价,只有中等规模机房的1/5,甚至到1/7。

想起一个老笑话,某公司的销售经理向老总汇报工作,说,“有两个消息,一个是好消息,另一个是坏消息,您想先听哪一个?”

老总说,“先听好消息吧。”

销售经理回答,“我们拿到了一个大订单。”

老总问,“那么坏消息呢?”

销售经理回答,“这个订单是Walmart下的。”

13.云计算经济学之时间成本

前文说到,伯克利大学的研究人员算了一笔帐,比较企业自建机房,与租用云计算平台的成本。结论是,租比造好。

成本不仅仅反映在金钱,而且还有其它方面,譬如时间和声誉。声誉如何折射成成本,可能不太好理解,但是时间是成本,这很显而易见。先谈时间。

文章举了一个例子,说是2008年3月19日,美国国家档案馆解禁了一批档案,其中包括希拉里(Hillary Clinton),作为第一夫人,在克林顿任总统的八年间,每日生活的起居录。这份档案共17481页,全部是PDF格式。华盛顿邮报得到这份档案后,指定一位工程师,让他把文件从PDF格式转换成便于搜索的格式。

如果用一台服务器,这份工作需要花费1400多小时才能完成。但是这位工程师租用了200台Amazon EC2服务器,做并行处理,前前后后总共只花了9个小时。

“云而上”这篇文章着重强调,租用一台EC2服务器,运行1400多小时,与租用200台服务器,运行7个小时,费用是一样的。以此来强调,云计算超大的并行计算能力,非常适用于高性能计算(HPC,High Performance Computing)。

高性能计算(HPC)的应用很多,海量文本处理是一个例子,科学实验数据处理也是一个例子,令人感兴趣的另外一个例子是动画电影。

文中提到好莱坞Pixar 制作室也是云计算的用户。Pixar studio以制作计算机动画见长,曾经获得21项奥斯卡奖,4项金球奖,以及3项艾美奖。1979年成立,当时是拍摄“星球大战”的Lucas电影公司 的一个部门。1986年该部门卖给Apple的创始人Steve Jobs,成为一家独立公司。2006年卖给迪斯尼公司,折价74亿美元。

计算机动画的数据处理量大,耗时长,用云计算平台,做大规模并行处理,实在是一个好应用。

Computer Generated Imagery Animation (CGI-Animation)

云计算做并行计算的能力,能够大大缩短数据处理的时间,这一点大家都不怀疑。令人担忧的是把海量数据上传到云上去,以及把海量数据从云里下载下来,所需要 花费的时间和金钱。所以,有人开玩笑说,云不是问题,问题是云雨。

话是糙了点,但是问题很中肯。文章中举了一个例子,如果想把10TB的数据,从伯克利大学通过互联网,上传到位于西雅图的Amazon云计算平台,需要 4,000,000秒,也就是45多天。而且还要支付1000美元网络带宽费。无论从时间,还是金钱,通过互联网传输10TB规模的数据,代价都是非常高的。

如果用邮递方式,把光盘寄过去,需要多少时间和金钱呢?最快的邮递方式是隔夜速递,也就是最多24小时。如果每张光盘存放1TB数据,那么总共需要10张 光盘,邮费大致是400美元。

45天 vs 1 天,1000美元 vs 400美元。互联网时代传输海量数据,高科技网络反而比不过传统物流,实在有点反讽。

为什么互联网带宽费用这么高?文章说,光缆并不贵,贵的是高端的路由器。带宽费用的2/3,用于支付高端路由器的购置费。说到这里,文章提到,一个“激 进”的解决办法,是用众多廉价的路由器,去取代高端的路由器。

哦也,如果说云计算是用一堆廉价的机器,去取代大型机(Mainframe),有人在试图用同样的思路,去取代高端路由器!

14.云计算经济学之声誉成本

前面谈的是时间成本的问题,接下来谈谈声誉成本。

文中给了列举了Amazon云计算平台,Google的AppEngine平台,以及Google的邮件系统Gmail,在2008年度因故障而停运的时 间和原因。

文章的笔调很幽默,说Google把大家的期望值炒得很高,以至于每当Google搜索引擎没法用的时候,人们的第一反应是网络断了,而很少有人怀疑是 Google服务器坏了。但是事实上,Google也好,Amazon也好,只要是机器,的的确确就有出故障的可能。

Outages in AWS, AppEngine and Gmail

当云计算平台出现停止运行的时候,损失的不仅仅是金钱,而是用户对云计算平台的信任。失去了用户的信任,必将逐渐失去市场。所以,维护云计算平台的声誉, 也是成本的一部份。

怎么办?文章给出的对策是让用户同时使用多家公司提供的云计算平台,互为备份,万一其中一家云计算平台暂时中止服务,还有另一家作为备份。但是这个办法有 两个问题,

1. 各家公司的云计算平台之间必须提供统一的APIs和Protocols。

2. 让用户同时使用多家云计算平台,会增加用户的使用成本。

要解决这两个问题,难度不小。

造成云计算平台中止服务的原因,不仅包括云计算平台自身的bugs,而且还面临来自外部的恶意攻击,其中尤其以DDOS(Distributed Denial of Service)杀伤力最大。

DDOS的做法是这样的,预先想办法劫持一大批电脑,劫持的办法是给这些电脑植入木马。预先计划好某个时刻,时间一到,激活所有木马,让它们同时访问同一 个网站,造成目标网站超负荷运行,导致该网站接待不了正常的用户。

怎么抵抗DDOS攻击呢?“云而上”一文给出的办法是扩大云计算平台的规模,让DDOS在经济上得不偿失。

“云而上”文中有一段犯罪经济学分析,

1. 假设攻击的目标是Amazon的EC2云计算平台。每个EC2服务器同一时刻只能承受500个访问者,而EC2平台总共有1000台服务器。

2. 为了造成所有EC2服务器瘫痪,攻击者必须招募1000 x 500 = 50万个木马,同时发动攻击。据调查,黑市上出售每个被劫持电脑里的木马的价码是每周3美分,如果攻击者想招募50万个木马,那么他需要投资1.5万美 元。

3. 如果Amazon EC2平台1000台服务器被瘫痪,以Amazon目前的标价算,Amazon每小时将损失360美元的流量费,外加每小时100美元的计算处理费,总共每小时460美元。这是Amazon损失的上限,因为实际上不可能所有EC2服务器都有业务。通常情况可能只有60%到80%的服务器有业务,所以实际损失是,276美元到368美元。

4. 因为攻击者预先支付的招募木马的费用是1.5万美元,所以攻击者一定想让Amazon损失1.5万美元以上,否则得不偿失。这样一来,木马攻击的持续时间 不得低于,15000 / 460 = 32 小时。换句话说,如果攻击的持续时间不足32小时,那么攻击对于Amazon的伤害,将低于攻击者付出的佣金。

5. 攻击的胜负手在于,Amazon是否有能力在32小时内,修复被攻击的EC2服务器。以现在的技术手段,及时修复的可能性很大,所以Amazon有更多胜 算。

6. 如果Amazon的EC2平台,不只有1000台服务器,而是有2000台呢?那么攻击者必须招募100万个木马,也就是必须投资3万美元。攻击时间仍然 不得低于32小时。这样一来,攻击者的风险就不再是1.5万美元,而是上涨到3万。

7. 如果Amazon的实际损失,每小时不足460美元,而是276美元。那么攻击时间必须持续更久,15000 / 276 = 54 小时。攻击时间从32小时延长到54小时,修复受损的服务器的可能性更高,Amazon的胜算更大。

总之,文章的结论是云计算的规模越大,抵抗DDOS攻击的胜算越大,越有利于维护企业的声誉。

这段犯罪经济学分析很有启发,但是也有疑点。

1. 每个木马可以同时对多个目标IP地址发动攻击。如果一个木马可以同时对5个IP地址发动攻击,那么攻击者不需要招募50万个木马,而只需要10万个木马。 换句话说,这段犯罪经济学分析,可能高估了攻击者的成本。

2. 文中说,每瘫痪一台EC2服务器一个小时,将给Amazon造成460美元的损失。问题是,如果每一台EC2可以同时服务多个用户,而不是一个,那么给 Amazon造成的损失就可能比460美元高。换句话说,这段犯罪经济学分析,可能低估了Amazon的损失。

3. 这段分析着眼于Amazon现金的损失,但是声誉的损失难以量计。所以,即便从现金流上看,攻击者貌似得不偿失,但是如果能够极大地损害Amazon的声 誉,或许攻击者还是会觉得合算。

15. 商机在于为人民服务

以大型机(Mainframe)为代表的超大规模计算和存储能力,以前为少数机构专有。旧时王谢堂前燕,飞入寻常百姓家,现在云计算风起云涌,超大规模计算和存储能力,为普通企业甚至个人敞开了大门。问题是,一旦拥有了超大规模计算和存储能力,广大人民群众能做什么?

1. 网络存储。

数码相机现在越来越多,加上手机也能拍照,每日全球新产生的数字照片可谓海量。以前这些照片大都存在个人电脑里,有了网络存储,这些照片的归属越来越倾向于 网络存储。

Flickr,Picasa,以及Facebook等等社交网,都可以提供照片的网络存储。目前主要的问题还是在网络上传的速 度比较慢。长期来讲,终极的解决办法是建设下一代超大带宽的互联网。但是在目前,Flickr,Picasa等等争夺市场的最简单,最有效的办法,看来是开展邮递业务。用户把需要上传的照片刻成光盘,邮递至Flickr和Picasa,它们收到光盘后,批量上传。

类似的机会,还存在于文本 文件,视频,音乐等等。

2. 网站托管。

自己动手建一个网站,事务性的工作要占据很多时间精力,注册域名,购买设备,租用机房等等。后来有人开展网站托管业务,但是网站建设往往必须限定网页设计的模板,后台逻辑处理也不能太复杂。有了云计算平台,网站建设有了更大的灵活性。网站普遍面临的难题,是流量忽上忽下难以预测,云计算平台的高弹性的计算和存储能力,为解决这个难题,提供了可靠的办法。

随着建网站 的进入壁垒降低,云计算平台供应商将面临的竞争,是如何尽快地更多地吸引潜在的客户,把他们的网站建在自己的平台上。譬如,如果想游说秀水街的小摊小贩们去建网站,单靠云计算平台供应商的销售人员挨家挨户上门兜售,恐怕效率太低。有效的办法,或许是采用授权(franchise)的做法。云计算平台与几家 大的经销商谈,说好每招徕一户网站,收入如何分配。然后由经销商去寻找下家客户或者经销商。经销商不仅负责营销,或许还可以负责帮助下家客户设计网站等 等。

3. 高性能计算(HPC)。

提到高性能计算,人们通常会想到天气预报,原子弹爆炸模拟,基因组合搜索等等。对于人们日常生活,目前似乎看不到高性能计算的影子。是日常生活不涉及高性能计算,还是有需求,只不过以前被压抑了?

以我看,需求是有的,只是以前普通人做不到,所以市场潜力没有充分被挖掘出来。譬如说虚拟现实(Virtual Reality)的应用就很广,可以用于游戏,也可以用于教学,例如射击,驾车,飞行,甚至做手术等等。

问题是制作虚拟现实的技术要求很 高,计算量也很大,所以普通人即使有很好的创意,也实现不了。有没有可能把三维计算机图形模型,尽可能多地模板化,元素化。普通人如果有好的创意,可以基于这些模板实现个性化设计,然后把诸多元素组装起来,实现一个一个的场景。

4. 数据挖掘。

数据挖掘的关键,在于数据的采集。Tim O’Reilly说,“未来属于那些能够实时处理信息的服务,信息的来源既可以是用户,也可以是非人力的传感器(The future belongs to services that respond in real time to information provided either by their users or by nonhuman sensors)”。注意句中提到的传感器,相对于人力产生的信息,传感器上传的数据,更及时,更丰富。

UC Berkeley’s micro sensor mote.

问题是传感器能收集什么样的数据?森林防火, 建筑筋梁的应力监测,这些已经有人在尝试。有没有可能实时远程监控,例如监控在家疗养的病人的身体状况,这样既不占用医院的病床,也不耽误及时救治。

非人力产生的数据,不仅来自于传感器,而且很多设备也在无时不刻地产生大量数据,例如无线网络的设备,它们记录了每一部手机从一个基站转换到另一个基站发生的时间。这些数据目前白白地被浪费,如果收集起来,尝试各种数据挖掘算法,或许能够启发出以前想不到的应用。沿用前面的例子,通过对无线网络数据的挖掘, 不仅可以实时测算人口的分布,而且可以估算各个主要道路的交通流量,以及人流车流的速度。

5. 前店后厂。

北京有一家餐 馆,叫“张生记”,它的招牌菜是老鸭汤。但是去张生记品尝老鸭汤,往往乘兴而去,败兴而回。因为餐馆只有8个炖汤的炉头,客人多了供应不过来,只好抱歉地通知顾客,此品告罄。给他们经理出了一个主意,或许可以在郊外租个厨房,专门批量炖制老鸭汤。每天早晨,把炖好的老鸭汤运进餐馆,有食客点此菜,只需回锅加热即可。这个主意,就是前店后厂。后厂完成主要工序,前店只要做简单处理,即可服务客户。

“云而上”一文提到Matlab和 Mathematica两个软件,说对于复杂的计算,不一定要全部在PC本地完成,Matlab和Mathematica可以把一部份运算量庞大的任务, 转发给远程云计算平台去完成,PC本地只负责运算量小的任务,以及结果的显示。这个主意也符合前店后厂的想法。

前面提到的游戏的图像制 作,也是前店后厂的思路。前店负责设计,设计完成后,软件及时给设计者一个简单的二维静态效果图。设计者确认后,让后厂负责完成三维渲染,以及动画控制等等计算量繁重的工作。

前文提及的新浪音乐盒,也是前店后厂的思路,前店主要负责播放,后厂主营搜索及推荐。

当人类普遍拥 有了超大规模的计算和存储能力,软件设计以及算法实现,都可能会发生一系列转变。前店后厂的模式,或许可能成为这一系列转变的第一个尝试。

后厂与云计算挂钩,已经没有太多悬念,困惑在于前店该如何设计。这个专题,留给后文讨论。

16.政策的猫腻

有人评论美国的科技政策,说自从爱迪生时代以来,美国每每发现一个潜力不错的主题,就像抛绣球一样,忽悠各路学界商界人力财力去钻研,去哄抢。这些人力财力,不仅来自美国本土,而且也来自全球各地。美国政府通常在幕后指挥,它的作用主要体现在两个方面,

1. 通过公开的立法,以及暗地的操作,让美国本土公司机构和个人得到最大实惠,同时也留一点残羹剩饭给海外尝尝甜头,保持他们参与的积极性。

2. 率先发现富于潜力的主题。从福特汽车,贝尔电话,通用电器,好莱坞电影,杜邦化工,波音/洛克希德航空航天,到Motorola/Texas Instrument电子,Intel集成电路,微软操作系统,思科网络设备,Netscape/Yahoo互联网相关产品,和Google搜索引擎。科技突破转换为商机的重大机会,几乎都被美国把持。

为数不多的例外之一,是移动电话。1980年代末,移动电话技术在北欧以及日本已经很成熟,但是美国迟迟不开放市场。直到1990年代初,Qualcomm和Motorola等等美国本土公司技术准备充分以后,美国政府才默许大规模开发本地移动电话市场。Nokia等等海外公司,固然能够在美国市场得到一部份利润,但是主要收入,还是留给了美国本土公司。

计算机和网络技术美国一直处于领先地位,所以美国政府对待计算机和网络,明显与移动电话不同,没等到技术十分成熟,就已经迫不及待地向全球抛出这个新绣球。先是Apple和 IBM两家美国公司饱赚了PC的利润,接下来微软和Intel又赚得盆满钵盈。

互联网原本是欧洲人的发明,问世不久,就被美国人抢过风头。当时互联网作为一个新兴产业,从技术到商业模式,都没有成型,美国人挥舞金融股市指挥棒,吸引各国资金,以风险投资为渠道,糜集美国,催生了一大批互 联网相关企业。而这些企业的股票一路疯长,又反过来刺激全球资金进一步向美国聚集。一转眼,到了2000年,互联网泡沫破灭,大批海外资金血本无归,但是这些资金所催生的技术与实物资产,却留在了美国。

互联网的潜力还没有挖晚,美国又开始忽悠生物基因和医疗药品技术。生物基因和医疗药品技术,从学术研究转化为商品生产的难度,似乎比计算机和网络更难。到目前为止,除了伟哥获得了商业上的巨大成功以外,还有多少其它成功案例?但是去硅谷数一数,生物公司已经为数不少。这些公司以什么生存?答案,风险投资。美国人的魔术,依旧长盛不衰。

客观上来说,云计算算不上是一个特大的绣 球,但是架不住美国的热炒,现在已经成为全球IT业界的热点话题。

目前云计算商战战场是三国鼎立的局面。Google AppEngine面向广大网站客户。Amazon S3和EC2更在意托管电子商务,以及代理高性能计算。这两者的目标客户,基本上都是企业客户,包括小摊小贩。微软呢?微软的云端战略强调的是那个“端” 字。有理由相信,微软更在意个人用户。

IBM的处境有点尴尬。云计算本质上来说,对IBM的大型机业务是威胁。但是IBM奇怪地推出 Blue cloud战略。细细琢磨一下蓝云的技术内容,发现除了Tivoli这个监控系统以外,蓝云的核心,都依赖于开源项目。而Tivoli与云计算的关系,充 其量不过是个辅助工具而已。

对于自己不擅长的技术,IBM为什么不唱反调,反而跟着别人后面起哄?“云而上”这篇文章给出的答案是,维护 客户关系(leverage customer relationships)。说来也不奇怪,IBM日益从一个硬件软件生产商,向服务与咨询方向转变。

一个当年主宰着计算机产业,一个当今仍然拥有人才荟萃的T.J.Watson等等实验室的IBM,在云计算这个重要的领域,却没有一如既让地担当起领袖的重 任。时过境迁,一声长叹。

17.商战与和平崛起

有人评论和平崛起,说可以归纳成两个尊重。尊重现有国际惯例,尊重现有国际秩序。惯例容易理解,法律,规范,标准等等的总称。秩序怎么理解?对方笑道,就是不要挑衅老大。但是对待老二老三,间或可以小打小闹,基本以和为贵。至于对付三甲以外,不妨正言厉色,晓以利害。

按照这种说法,云计算的前三甲,已经基本定型,分别是Amazon,Google和Microsoft。谋图和平崛起的后来者们,能做的是在尊重现有国际秩序的框架内,做一点拾遗补缺的工作,融入主流。

云计算平台还有什么拾遗补缺的工作呢?

1. 统一云计算数据存取的APIs和Protocols,打消客户担心被劫持的恐惧。

“云而上”一文提到,从2006年到2008 年,Amazon的EC2和S3平台对存储空间的收费,降低了20%,对网络带宽的收费,降低了50%。对于客户来说,这当然是好事情。但是反过来想想, 如果Amazon不降价,用户有什么反制手段呢?随着用户把更多的数据存储在云技术平台上,用户对于云计算平台供应商的反制手段越少,反制力度也越小。这 就是用户被劫持的恐惧。

如何打消用户对于被劫持的恐惧?办法是统一各个云计算平台之间,数据下载和上传的APIs和Protocols, 方便用户从一个云计算平台向另一个转移数据。

当然,统一APIs和Protocols的工作,取决于云计算平台寡头们的谈判结果。但是, 一旦达成了统一的APIs和Protocols,受益者不仅仅是云计算平台的用户,而且也为云计算平台的小供应商提供了机会。

2. 云的弹性与反应速度。

“云而上”一文反复强调,云计算的优势在于应付忽上忽下的流量,云计算能够提供伸缩自如的计算和存储能力。所谓伸缩自如,就是在流量暴涨的时候,可以扩张计算和存储能力,反之,在流量萎缩的时候,可以减少计算和存储能力。

问题是,如何在最短时间内, 迅速地扩张和减少?“云而上”一文给出的办法,是尽可能提早预测流量的变化,至于怎么实施,文章没有详谈。

或许更直接的办法,是尽可能快 地复制和取消虚拟内核的。譬如如何把Xen domains从一台机器,向另一台机器快速复制,或者取消已经存在于某一台机器内的Xen domains。

这两个办法,技术上都存在问题需要解决。技术的挑战,往往是后来者发展的机会。

3. 机器硬件的改造。

“云而上”一文援引资料,说直接与机器的memory交互,读写数据,速度很稳定,平均速度是 1355 Mbyte/Second。而向机器的硬盘写数据,速度不稳定,平均速度是 55 Mbyte/Second,而且有超过16%的机会,写硬盘的速度低于 9 Mbyte/Second。换句话说,硬盘的带宽只有内存带宽的1/25。

如何提高硬盘IO的带宽,成为热点问题。

“云而上”一文建议的解决办法,使用Flash memory替代传统的光盘。这意味着,传统的计算机硬件结构,将面临转变。

4. 安全问题。

“云而上”一文断言,安全方面不存在严重的挑战。我们觉得,这个断语可能过份乐观了。

如何防止云计算平台供应 商偷窥用户的数据和程序?“云而上”一文提出的办法是给用户的数据和程序加密,只有当用户自己读数据和运行程序时,才解密。

且不说加密和 解密导致的计算量增加,如何对加密的数据进行搜索?

美国第二大零售店,Target,把自己的网站托付给Amazon运营,实在是冒险的行为。

看来最可行的办法,是给每个用户分配相互隔绝的虚拟空间,譬如Xen domains。把每个用户的数据和程序,放在密室里暗箱操作。但是问题并不仅仅在于防范一个用户偷窥另一个用户的数据和程序,而是防范云计算平台的供应商偷窥用户的数据和程序。供应商具有每台机器root的权限,所有Xen domains里面的数据和程序,都在root的视野内。

所以,归根结底,是限制root的权限。但是这个工作,涉及对Xen的改造。或许,这也是后来者发展的机会。

5. 为企业构建私有专用云计算平台。

安全的问题不好解决,所以必然有潜在的云计算客户,希望构建私有专用的云计算平台。

后来者们开展业务的另一个空间,是做咨询公司,帮助这些企业构建属于它们自己的一朵朵小云。

6. 传统Database将面临挑战.

Oracle,DB2,MySQL 的设计,在扩展性(scalability)方面都有缺陷。Google的Bigtable,或者开源项目Hadoop/HBase,在扩展性方面有更大的潜力。

对于后来者而言,未必要全面争夺云计算市场。或许集中精力,深入挖掘Hadoop/HBase的潜力,也是不错的机会。

7. 内容为王。

云计算大战,各路诸侯逐鹿中原,一场混战以后,谁将是最后的王者?

或许,谁占有了更多的更好的内容,谁更有可能最终胜出。

只要网络带宽的发展跟不上计算机硬件的发展,Jim Gray的结论就依然有效,数据的处理应当放在离数据更近的地方。所以,谁占有了更多高品质的内容,就会吸引大家去挖掘利用这些内容,提供更好的服务。有了更好服务,就会反过来刺激人们把更多更好的内容上传到这个云计算平台。如此循环往复,形成正反馈。

Amazon正在游说美国政府,免费提供S3存储空间,保存美国人口普查等等大型数据。或许,Amazon的战略考虑,正是看准了内容为王。

结束语

一篇好的论文,总是能引发很多思考。

拿到这篇“Above the Clouds: A Berkeley View of Cloud Computing”,一口气读完,已经午夜以后。第二天上班路上,想想又觉得不对,似乎文中有些观点未必让人信服。晚上重读,发现先前自己的理解不准 确。又过了一天,再次觉得文中的确有商榷之处。如此反复。

Google式云计算之所以吸引人,在于穷人也玩得起。凑几台廉价的PCs,再弄一两个网络交换器(Switch),就可以动手实践了。麻雀虽小,五脏却俱全。

云计算到底好不好?毛主席早已有答案。毛主席语录如是说,梨子甜不甜,咬一口就知道。


 
分享到
 
 


专家视角看IT与架构
软件架构设计
面向服务体系架构和业务组件的思考
人人网移动开发架构
架构腐化之谜
谈平台即服务PaaS
更多...   
相关培训课程

云计算原理与应用
Windows Azure 云计算应用