Netflix 开发者大赛,云计算 1.0,还是 2.0?

阅读数:834 2013 年 4 月 6 日

话题:DevOps架构

Joe Emison 是 BuildFax 公司的 CTO 和创始人,该公司为企业提供地产方面的数据,在技术架构上以云计算为基础。最近,Joe Emsion 在信息周刊上发表文章《Netflix 如何毁掉云计算》,指责 Netflix 最近举办的云计算开发者大赛抱有“以 AWS 为中心”的心态。

Emison 认为:Netflix 是“云计算 1.0”时代的典范,表现出了巨大的收益,也暴露出不少问题。

云计算 1.0 基本上就是 Amazon Web Service 的事情,它是第一家,也是唯一一家,提供的特性能够满足构建相当大规模应用的需求。因此,Netflix 拥抱 AWS 很正常。但是在云计算 1.0 手中,Netflix 在 2012 年就遇到 4 次故障。最大的一次在圣诞节前夜,依赖一个不是很重要的 AWS 负载均衡服务,是问题的主要原因。

而最近 Netflix 设立的头奖 10 万美元的开源云计算管控工具大赛,更是被 Emison 认为:

这种做法,会让未来几年的云计算实践和架构都处于十分被动的局面。 …… 因为这个做法完全是“云计算 1.0”的思维模式,建立在“Amazon 是唯一厂商”这个观点的基础之上。 …… Netflix 这个以 AWS 为中心的竞赛令人生厌,除此之外,还有更深层次的问题:Netflix 有些工具所考虑的架构,在云计算 1.0 时代没有问题,但随着时间推进,问题越来越多。对于一家公司来说,很难放弃目前没有问题的代码和系统,特别是它们看起来很不错的时候,而且还能争取一点时间,上述都是正确的内部决策,这些我都可以理解。但是,Netflix 没有自己努力从中绞出最后一点价值,而是把大把钞票扔到外面,让所有人都去拥抱、扩展他们的工具和代码,而这些代码和工具对于未来的云架构来说,算不上多么好的实践。

接下来,Emison 列举了 Netflix 的 Aminator 工具,作为 Netflix 不良实践的例子。该工具基于一个 AMI 模板和一些代码,使得更易于批量构建 Amazon Machine Image 镜像。他认为:该工具几年前用还可以接受,但现在:

如今,我们已经有了 Chef 和 Puppet 这样广泛使用的配置管理工具,再大规模创建 AMI 就不是什么好实践了。AWS 自己最近还发布了 OpsWork 服务,用它处理应用部署要好得多,它就用了 Chef。

他还列举了 Edda 和 Asgard,指出这些工具:

在架构上,是为了解决一些多少已经解决了的问题,这就像是一个仍在频繁依赖和使用 SOAP 的开源项目,而不是用 RESTful 方法。

不过他认为 Denominator 还是一个出色的 DNS 管理工具,Simian Army 对于测试云架构来说,是一个极好的、有开创意义的想法,可惜,只能用在 AWS 上。

Emison 在文末指出:

有可能 Netflix 的竞赛会将世界引向云计算 2.0 时代,拥抱多云架构,同时使用写作和配置管理作为最优的方式。……但 Netflix 刚刚发布 AMInator 这个事实说明:Netflix 很乐意推广他们开发的任何工具,不管这些工具是否符合当今云架构的最佳实践。

针对 Emison 的这些观点,Netflix 的云架构师 Adrian Cockcroft 在自己的博客上做出了回应

他先对比了“云计算 1.0”和“2.0”:

我认为:大部分人目前用云的方法,是把一部分现有的架构迁移到云中,运行混合的设置环境。这是我眼中的云计算 1.0。Netflix 所做的,是开发灵活度更高的原生云应用,这更适于成为“云计算 2.0”。至于底层用哪些特定的 IaaS 服务,或者是否用公有云和私有云,这与我们构建的架构无关。

对于可移植性问题,他认为:

其他云厂商的功能和规模,还只能相对于 Amazon 在 2008 到 2009 年的水平。我们还在等他们跟上来。他们做出了很多承诺,但对 Netflix 而言却没多少能用的。不过,还是有些小规模而且更简单的应用有使用 NetflixOSS 的需求。Eucalyptus 在公共云和私有云中都已经把 Asgard、Edda 和 Chaos Monkey 跑了起来,而且会放在 Eucalyptus 3.3 中交付。还能看到一些信号,人们想要在 OpenStack、CloudStack 和 Google Compute 中加入一些缺失的功能,让 NetflixOSS 能在上面运行。

至于 AMinator 工具,他认为有其特定优势:

如果你想要启动 500 个完全相同的实例,在它们启动后各自运行 Chef 或是 Puppet,很容易让它们依赖 Chef 或是 Puppet,浪费启动时间,而且如果安装出现问题,就会得到一堆不一致的实例。使用 AMInator 在构建阶段只运行一次 Chef,这就降低了运行时出现问题的几率。

对于 Netflix 举办的大赛,Adrian 的回应是:

奖励中包含可移植性的类别,这个类别很广,要是有人为 NetflixOSS 加入其他编程语言的支持,比如 Erlang、GO 或是 Ruby,或是让 NetflixOSS 能够运行在更多 IaaS 选择之上,都有可能获奖。现实情况是:AWS 确实统治了目前的云部署市场,所以,能在 AWS 上运行,也就能保证能让最多人收益。很多人都在吹捧 AWS 之外的方案,但它们都还有一段路要走。

Joe 也看到了这篇文章,并在评论中说道:

我认为你的回应是只见树木,不见森林。

森林是这样的:Netflix 的云架构,不管是从公开演讲还是从开源代码中看,从根本上,

a)跟 AWS 紧密交织,基本上是无法分离的;

b)从配置管理和协作角度来看,大大落后于最佳的“通用”开放解决方案。

同时远远落后于“Unix 方式”——封装、抽象可与其他彼此互相交换使用的工具,无法构建最佳架构。

……

Netflix 在云架构领域中,有很大的权力和影响力,很多人都指望着 Netflix 指导他们如何完成云部署。如果从长远考虑你的云架构,Netflix 做出的一些选择就是不好。从历史上看,也很难引证好的先例,证明这样跟一家 IT 厂商紧密交织是好的决策。对于在云中部署的人们来说,不管出于什么目的和意图,了解、理解配置管理,远比会用某种可以忽略这个过程的工具来得重要得多。

Adrian 和 Emison 在评论中展开一系列交锋,感兴趣的同学,可前往关注。

坐在大洋彼岸隔岸观火的我们,恐怕大部分人都没有太多机会真正使用 AWS,1.0 还没有尝到甜头,奢谈 2.0 似乎有些为时尚早。但他们的讨论还是可以给国内的公共云运营商以启示,对广大想要使用公共云的开发者们来说,更是一个提醒。不管 1.0 还是 2.0,先把配置管理弄明白才是最重要的事。