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