谷歌计算引擎:到底是什么让你迟迟无法面世?
jopen 12年前
<p> 英文原文:<a href="/misc/goto?guid=4958346959487046888">Google Compute Engine: What took them so long?</a></p> <p> 兜了一个大圈,最终我们又回到原点。当下最流行的技术概念——云计算——终于在谷歌那里得到明确回应。相信大家一定等这一天等得花儿都谢了,因为谷歌其实是最有机会开创云计算先河的企业,企业高管们也始终在热切期盼廉价质优的谷歌服务器能够帮他们在商业计算领域再燃一把希望之火。覆盖一切的资源池、在需要的任何领域提供处理性能、不必担心浪费也永远没有宕机,谷歌的品牌号召力与云似乎有种天作之合般的默契。</p> <p> 与此同时,IT 管理者们则瞪大了惊慌的双眼注视着这一历史性变革。他们的反应非常合理,因为严峻的问题已经被摆在面前:没人能借助有限的资源达到谷歌所造就的高度。在残酷的市场竞争下,谷歌为每位用户提供了一种便捷而经济的工作方式,复杂而脆弱的数据中心将成为过去,美好的未来已经以实验性方案的形式展现在我们眼前。</p> <p> 然而,距谷歌首次发布其 App 引擎开发平台至今已经过去了四年,现在他们终于下定决心在公共云 IaaS 市场中插上一脚——目前这块市场属于 Amazon 公司一家独大——并以谷歌云计算引擎为依托将一部分基础设施向用户租赁。这份公告来得可谓恰到好处,因为目前消费者们已经对云计算有了相当程度的掌握,也比较了解创建自有云环境的艰辛与昂贵。而在与其他 IaaS 供应商的合作中,他们还逐渐体会到外包工作负载所带来的各种局限。</p> <p> 谷歌计算引擎到底会在 IaaS 组合方案中扮演何种角色?目前还很难判断,因为我们从公告中得到的重要细节少得可怜。上周我曾与谷歌计算引擎项目的产品经理 Craig McLuckie 短暂交谈过,他看起来似乎对谷歌在全球范围内享有的极高声誉信心满满,并认为长久以来的成功经验以及一流基础设施必然会给新产品带来大量客户兼脑残粉。</p> <p> 面对 McLuckie,我的核心问题是:为什么选择现在?谷歌早在数年前就已经意识到云技术中所蕴含的强大潜力,为什么没有提前推出产品呢?他是这样回答的:</p> <p> 要拿出成熟的产品投放市场可不是一朝一夕之功,而整个过程中最关键的部分无疑是核心技术。我们的奋斗目标绝不仅仅是对当前多租户云的简单照搬,而是给我们的消费者带来一套亲切、容易上手甚至在使用感受上与自有数据中心非常接近的产品。我们关注的是性能的可预测性,我们关注的是基础设施访问的简洁性。基于这些考量,解决方案的出炉确实很费了我们一番功夫,但我认为这种努力是值得的。谷歌的最终产品完全超越了其它多租户云方案,而且即使与自有数据中心相比也毫不逊色,这一点令我们非常自豪。</p> <p> 在他的发言中,大家一定会注意到“性能的可预测性”这种说法。这是在以不点名的方式给了 Amazon Web Services 一记响亮的耳光,Amazon 公司的这项服务几年来已经多次闹出影响很大的宕机故障。谷歌怎么会有如此自信,认为自己可以完全避免此类问题?McLuckie 告诉我,因为谷歌的基础设施更强力——呃,好吧,这倒也算是个理由。</p> <p> 上周在接受 InfoWorld 网站采访时,RightScale 公司创始人兼 CEO Michael Crandell 结合谷歌利用高速网络连接全球各地数据中心的方案,对这套全局基础设施发表了自己的看法。但随着计算引擎项目的正式启动,谷歌显然有点忘乎所以,他们的宣传核心始终围绕着自身品牌价值以及数年前轰动一时的先进基础设施。</p> <p> 再回到标题提到的重点问题:到底是什么原因令计算引擎心无法面世?McLuckie 给出的“好饭不怕晚”一说似乎无法令人信服。首先,计算引擎直到目前还连个测试版都没有,只提供什么“有限预览”。如果谷歌基础设施真像他们宣传的那么强劲,为什么要在细节规划上花这么多时间跟精力呢?要知道,这类产品的作用只是向消费者提供云计算资源、服务以及技术支持,而谷歌在这些方面的经验其实并不丰富——这从谷歌应用付费版本的质量就可见一斑。</p> <p> 为什么软件开发工作耗时如此之长?去年秋季,一位名叫 Steve Yegge 的谷歌工程师无意之间走漏了风声。Yegge 曾经在 Amazon 工作过一段时间,他撰写了一篇本应只供谷歌内部参考的博文,但却一时不慎将其发布在 Google+ 上。</p> <p> 在博文中,Yegge 详细介绍了 Amazon 公司 CEO Jeff Bezos 在 2002 年做出的关于“各团队通过服务接口公布数据及功能”的规定。也就是说,Bezos 希望以强制性手段令 Amazon 将公司业务朝着面向服务转型。在 SOA 得到正确实施的前提下,共享服务能够大大缩短开发时间,因为开发团队中的每位成员都能通过 API 调用现有开发成果,而不是一切从零做起重复编码及功能。当设想按部就班成为现实,企业现有应用程序基础设施将转化为通用平台。</p> <p> 而与之相比,Yegge 指出谷歌则“没能打造出这样一款全局平台。”在谈到公司采取的内部开发规定时,他说:</p> <p> 即使仅仅为大多数技术团队提供暂时性的数据及计算编程访问服务,其工程量同样相当浩大。谷歌公司的大多数员工都只关注如何努力开发产品,而暂时性服务则往往被视为浪费时间和可笑的理想化目标……我们所面临的问题非常严峻,因为只有从本质上改变谷歌的企业文化,才有可能迅速缩短这几年来被 Amazon 所甩下的差距。我们没有打造出这类面向服务的内部平台,是因为我们在企业外部也同样没做过这种工作。</p> <p> 就我个人而言,这种论调只能算是种猜测,但 Yegge 提出的问题倒确实在一定程度上解释了谷歌为什么花了这么长时间来为谷歌计算引擎打造相关软件产品。</p> <p> 根据我与 McLuckie 之间进行的交谈,他似乎明显还没有感觉到谷歌对于打造自家 IaaS 品牌的必要性与紧迫性。当然,这种状况我也能理解,毕竟这是谷歌——拥有世界上最先进基础设施的庞大技术帝国,他们的技术财富令无数人垂涎三尺,不是吗?而且无论到底何时才会将有限预览转化为测试版本乃至完成版(包括今后的服务水平协议等内容),至少谷歌计算引擎已经正式被纳入议事日程,而且根据 McLuckie 的说法,谷歌终有一天会拿出令人惊叹的完美作品。</p> <p> 毫无疑问,谷歌将成为 IaaS 市场中一颗不容忽视的新星。而且尽管也出现过一些停机及其它差错,但充满神秘感的谷歌对于很多消费者而言仍然具备相当程度的吸引力。但另一方面,时代已经不同了,如今的云领域已经比四年前更加竞争激烈、危机四伏,普通的 App 引擎根本无法轻松打开市场并取得成功。谷歌未来要抗衡的不仅仅是 Amazon 与 Rackspace,新加入进来的竞争对手还包括惠普、微软、戴尔甚至多家电信运营商(例如 Verizon 公司以及 Terremark 公司等)。从这个角度来看,谷歌其实并不具备什么固有优势,它需要像其它 IaaS 供应商一家用实际表现证明自己的实力。</p> <div id="come_from"> 来自: <a id="link_source2" href="/misc/goto?guid=4958346960285089203" target="_blank">51CTO</a> </div>