Netflix 开发者大赛，云计算 1.0，还是 2.0？

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，先把配置管理弄明白才是最重要的事。