本文讲的是容器时代，这确实是我们想要的未来，
【编者的话】由于上一篇
容器时代，难道这就是我们想要的未来？
反响强烈，CircleCI的创始人Paul Biggar再次出山写了此文章。此文同样知识点非常很多，文字犀利，可以看出Paul Biggar是对于软件行业有深刻理解的人物。每个人对于容器生态圈或者Docker的看法有不同，希望从文章中读者能与Paul有些共鸣。
上周我写了一篇博客 It's the Future ，讽刺了容器生态系统，顺带嘲讽了下Docker、Google、CoreOS和一些其它技术。很多的Docker爱好者看起来是可以接受这篇文章的观点的，但也有很多人持反对意见。
也许很多人看完我的文章后会更容易理解为什么说容器的生态系统是被『炒』起来的。Docker是什么，这并不是那么容易理解。它是容器化的过程，类似于虚拟化，但并不完全是。Docker使用了类似于Chef的Dockerfile，并加入了一些称为层的文件系统。它所解决的问题与AWS、Heroku、VMware和Vagrant类似，但是每种情况的解决方式又有些不同。它与之衍生了27个相关的工具，而且每个名字都很滑稽，比如machine、swarm、flannel、weave、etcd、rkt、kubernetes、compose、flocker。不知何故Docker也和炫酷的微服务联系到了一起，微服务更有意思，它一开始考虑的是保持单个服务运行有多难，这似乎是一个非常愚蠢的想法。但就这样，微服务和容器看起来很流行，竟然有数十家创业公司和大公司都在支持它。
审视Docker和container生态圈后得出，他们都是bullshit，这真的不是不合理的！
它确实不合理。
实际上他们是我们如何构建应用的未来。
为什么会是新动力？
为什么有许多兄弟会赞同《 It's The Future 》文中的观点，因为这压根不是讽刺，他们也质疑整个容器的技术炒作。Docker和容器生态系统（在“Docker”之后）是应用开发圈讨论最多的话题，如虚拟化、面向服务架构和操作系统，并从不同的角度重新交付他们。可是这样一来，引起开发者社会里很多人的不满：那些讨厌新事物的家伙。
其实软件行业与你所期望的有所不同，这个行业里有太多讨厌进步的人。好比有这么一群人，他们进过米开朗基罗建成的西斯廷教堂，然后他们会宣布他们得到了一张完美的上帝图片，他们更喜欢自己的天花板是白色的，而且壁画不是很酷那种。
与此同时，大部分的软件产业商会像个高中生一样做决策：他们痴迷地寻求这个圈子里什么最流行；可能会在Instagram和Facebook上看一圈，然后盲目地跟从上面所说的流行技术。围绕这些技术，这些公司会形成一个圈子，他们甚至会刻意雕刻自己，使自己符合他所处的技术生态位（他们甚至会把笔记本电脑盖上他们帮派的色彩），他们还很讨厌并且抱怨那些他们不知道或跟他们不同的技术。
正如Docker的世界：它几乎改变了所有做事方式。它抛弃了操作系统、部署、OPS、打包、防火墙、PaaSes还有其他一切的旧规则。一些开发人员瞬间就爱上它，有些出于正当的理由，比如能解决问题，而有些是因为他们可以向别人炫耀他们懂这个新技术。有些开发者非常讨厌Docker（认为它纯属炒作），他们说：它跟之前的是技术一样的，我不明白为什么每个人都在谈论它。他们认为，在这个过程中感性大过了理性。
就技术本身而言，对Docker有这样的反应是完全没有必要的。大多数反对者并不是针对Docker对复杂问题的解决方式。更多的是因为他们根本没有注意到这种解决方案。如果你没有直观地、深入的去理解 “cattle not pets” 到底是什么和它为什么那么重要，那么当你面对Docker以及其相关工具解决问题的方式方法后，你会觉得很奇怪、很不可思议。
合并世界
Docker是两个学科的合并点：Web应用和分布式系统。在过去的十年，我们处在网络社区里，总会被告之，只要我们知道如何编码，就能构建Web应用程序。我们写一些HTML、JavaScript、Rails然后我们有了一个网站。再增加了一些forms、handlers，也许会加一个API，这样我们就大功告成了：这就足以推出的一款能够获得投资、客户和收入，甚至可以改变世界的产品了！同时，在过去的二十年中，分布式系统的那些人一直在做一些无聊的破事。他们实验过像CORBA和SOAP这样复杂的协议，学过像CAP定理这种方式解决问题，证明过时钟同步是不可能的，而这两大问题，都是以理论居多。对于那些只想用他们的技术编码和ship web应用的人来说，上面那些问题和解决方案毫无意义。
但随后有趣的事情发生了。Web应用程序变得非常大，以至于他们开始需要扩展。有太多的人上网，web应用程序在单一的VPS上再也呆不住了，他们只能进行垂直扩展。当我们开始扩展，我们看到了在应用中的所有BUG，这些BUG有一些非常有趣的名字，如“race conditions”、“network partitions”、“deadlock”和“Byzantine failures”。这些都是分布式系统兄弟们一直在努力解决的问题，而且解决这些问题不仅非常难，在很多情况下，这些问题在理论上是无法解决的。
在可扩展性危机的前几年，Heroku出现了。Heroku让基础设施的横向扩展非常容易，这再一次给了我们欺骗自己的理由，让我们觉得我们真的可以只是简单的做web app。我们觉得我们就是整个行业，也许我们在这种假装和自欺欺人中呆了5年。
我们现在打破了这种自欺欺人的局限，当我们从这个困局走出来，我们发现自己正在试图去构建易于扩展、易于重新构建的应用，而且我们也在尝试了解整体架构的劣势，了解为什么单一数据库不能为我们服务。后来我们想出像Immutable Architecture、“Pets vs Cattle”、Microservices这样的技术，我们尝试了很多好的、不好的解决方案，都是为了让事情变得更容易。
在这个转变过程中，Docker出现了，它试图去解决很多问题。但是，Docker没有像Heroku这样，告诉我们可以假装扩展问题不存在，我们仍然可以用之前的方式做事情，反过来Docker告诉我们，分布式系统是我们一直以来拥有的最根本的方式，我们需要去接受它，并开始研究这种模型。现在我们不用再去处理那些简单的问题，比如web构架、数据库和操作系统，我们得到了一些工具，像Swarm、Weave、Kubernetes、etcd等等，这些工具不是告诉我们任何事都非常简单，而是需要我们重新开始我们的工作，不仅仅是解决问题，是更深层次地去理解我们所要解决的问题到底是什么。
好的一面是，只要我们不逃避问题，我们现在有能力建立可扩展型架构。我们需要知道什么是网络分区、怎样处理它、怎样在AP和CP系统之间做出选择、怎样在恶劣的网络环境和机器下构建可自动扩展的架构。如有时弗吉尼亚州会是雷电天气，有时候会遇到火灾，有时鲨鱼会咬坏海底电缆，有时还有延迟、递送失败、机器挂了和内存泄漏等情况。
一切都需要更加有弹性，更加可靠，而且我们需要承认，这些都是我们在开发应用程序时需要考虑的事情。并且我们需要这样做不是因为它好，不是因为它是最好的实践，而是因为在像Amazon、Netflix、Google这样公司的人们，对这些问题的研究上已经有15年的血汗史和行业经验，他们告诉了我们如何构建真正规模的系统。
解决了实际问题
那么Docker究竟是为我们解决什么的呢？在我们建立web应用时做的每一件事都非常脆弱，而Docker让这些更合理化：- 到目前为止，我们已经从应用中（dev的一部分）分离出来，单独部署机器（DevOps的ops部分）。而且，我们已经有两个不同的团队管理这些应用程序栈。这样做是可笑的，因为应用程序依赖于机器和操作系统就像依赖代码一样，考虑把它们分开是没有意义的。容器将操作系统和app统一到了开发工具包内。
- 到目前为止，我们已经将服务性架构运行在AWS 、Heroku、其他IaaSes和PaaSes上，它们都没有管理服务性架构的工具。是Kubernetes和Swarm管理和编排着这些服务。
- 到目前为止，我们使用整个操作系统部署我们的应用程序，用了他们需要的全部安全脚本，而不是将这些应用部署最小化。容器允许你暴露一个仅需端口的很小的应用，甚至可以小到跟一个单一的静态二进制一样。
- 到目前为止，从机器产生我们就一直在摆弄他们，要么使用“配置管理”工具，要么在同一机器上多次重新部署应用程序。由于容器在流程框架内具有可伸缩性，所以只有不变的镜像会被启动、运行的机器不会重复使用，这样就消除了潜在的故障点。
- 到目前为止，我们现在使用的语言和框架都是为在单一机器上的单一应用而设计的。与面向服务型架构Rail同样的规则在这之前还没有。现在Kubernetes和Compose允许你指定跨服务的拓扑结构。
- 到目前为止，我们已经部署了由AWS部署的高虚拟化的服务器。我们不能说：“我想要的是CPU 0.1和RAM 200MB”。我们一直在浪费虚拟化的开销，而且一直在浪费资源，我们的应用根本用不了我们所使用的资源。而容器的部署相对简单，而且可实现更好的资源共享。
- 到目前为止，我们一直在用多用户操作系统部署应用和服务。Unix允许几十个用户同时运行，用户之间可以分享二进制文件、数据库、文件系统和服务。当我们要建立web服务时，这与我们所要的做的完全不匹配。再强调一次，容器容纳的只是简单的二进制文件，而不是整个操作系统，这样我们在我们的应用和服务中就不用担心太多。
唯一不变的就是变化
我们这行业发展的太快，神化了那些新的、令人兴奋的技术，以至于根本等不到这些技术的成熟。Docker正在以惊人的速度发展，这就意味着它没有接近稳定或成熟。对于容器的运行时间、镜像格式、流程控制工具、主机操作系统，我们有很多选择，每种都有不同程度的用途、范围，需要不同程度的扶持和社区的支持。环顾我们行业的其他部分，那些技术直到过时了才能逐渐稳定。有一个例子，在我们得到REST之前有多少协议已经不存在了？我们是踏着SOAP、CORBA的尸体建立起的REST、AJAX，在构建的时候吸取了很多经验。这两个 主要技术的过渡大约用了10年的历程。然而，我们仍然没有得到跟十年前的SOAP等同的基于REST的API工具，尤其是SOAP还没有完全消亡。
同样的故事发生在前端，而且确实很多兄弟会拿 前端开发正在做的蠢事 与我的Docker生态系统的滑稽文章作对比。自从我们十年前逃离Java，编程设计语言也在上演同样的故事。自始自终，开发者会不断拿出新的解决方案，直到问题都得到完美解决。更何况Docker生态系统有一堆问题需要解决。
因此我们期望Docker还不成熟。当你尝试的时候，仍然有许多衍生和奇怪的问题需要你去打破，当几年后我们回首它们，会发现一些决定不止是无法让人理解，实际上可能是完全错误的。最好的做法是要尝试、失败，再尝试试、再失败，直到我们真正地做好。
这将花费数年，我们才能领悟这一切，并让它平息下来。但是，这并不意味着容器是废物，或者说我们可以忽略它们。我们总是面临着选择，一面是继续使用我们已经熟悉的技术或者可以有一点小跳跃，一面是尝试新的东西、学习教训和适应、迭代、提升整个行业。
如果你要找我，我在未来等着你。
原文链接：it-really-is-the-future（翻译：周峰 审校：魏小红）
===============================================
译者介绍
周峰 ，在魔都互联网公司（饿了么）摸爬，架构工具组一员，致力于提供更好的工具支撑业务发展。同时喜欢参加各类活动，为容器技术的发展贡献微弱的力量。
原文发布时间为：2015-08-02
本文作者：小蜜蜂阿呆
本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。
原文标题：容器时代，这确实是我们想要的未来！
