容器时代，这确实是我们想要的未来！

由于上一篇《容器时代，难道这就是我们想要的未来》反响强烈，CircleCI的创始人Paul Biggar再次出山写了此文章。此文同样知识点非常很多，文字犀利，可以看出Paul Biggar是对于软件行业有深刻理解的人物。每个人对于容器生态圈或者Docker的看法有不同，希望从文章中读者能与Paul有些共鸣。

上周我写It’s The Future，讽刺了容器生态系统，顺带轻嘲讽下 Docker、Google、CoreOS和一堆其他技术。很多 Docker爱好者享受容器生态系统成为笑柄，但这篇文章也被很多人所喜爱而同样分享这篇文章的很多人叫嚣着“我告诉你，这一切都是胡说八道”。

正是我的这种讽刺方式很轻易的使人们可能认为容器生态系统是胡说八道。毕竟，轻轻一瞥很难理解Docker是什么 。这是集装箱，也就是像虚拟化，但并不完全是虚拟化。它有一个有点像Chef的Dockerfile，但它与一个涉及到无法理解的文件系统或其他一些所谓层的东西相结合。它和AWS、Heroku、VMware和Vagrant的目的一样解决了类似的问题，但在每种情况下，它的方式会和起初认知的总会略有不通，也存在真的永远搞不清楚它是什么。它有27种竞品工具，这些工具你不可能说出它们是哪些，它们有滑稽的名字如：machine、swarm、flannel、weave、etcd、rkt、kubernetes、compose、flocker。它不知何故和炫酷的微服务联系到了一起，但这是极其愚蠢的想法，当考虑到首先保持运行一个单一的服务它是多么困难。而在这一切之后，它有这种看不懂的态势被盛传，数十家创业公司和大公司都在竞相拥戴它。

这真的不需要再看看整个 Docker和container相关的技术，并得出结论：它就是废物？

但事实并非如此。

它实际上是我们如何构建应用的未来。

为什么会是新动力？

为什么会存在许多兄弟们认为It’s The Future是100％准确，这压根不是讽刺，他们质疑整个容器的技术炒作。

Docker和容器生态系统（以下简称“ Docker”）应用程序开发世界的集大成之作，如虚拟化，面向服务架构和操作系统，并与不同的目标和利益重新传递它们。至于它这样做，它引起大量的开发者社区的洗牌：守财奴怕一切的新东西。

软件产业，正如你所期望的，绝对是挤满了憎恶进步的人。有这么一群人，他们会走进米开朗基罗建成的西斯廷教堂宣布他们已经有了神的完美图片，他们更喜欢自己的天花板是白色的，而且壁画不是很酷的呢。

与此同时，大部分的软件产业做出决策，像一个高中少年：他们痴迷处处观察在他们的朋党哪些是酷的，他们也许看看Instagram的和Facebook的内容，然后盲从他们所引领的技术。围绕这些技术，它们构成帮派，甚至围绕技术生态雕刻自己的身份，他们不断适应，他们甚至在自己的笔记本电脑上盖上他们的帮派色彩，并且讨厌和抱怨那些陌生或者另类的技术。

正如世界之水Docker：做着几乎一切事情的新途径。它扔掉有关操作系统、部署、OPS、打包、防火墙、PaaSes和一切旧的规则。一些开发人员立刻爱上它，有时正当的理由，如能解决的问题，有时是因为它是一个闪亮的玩具，在其他孩子得到之前，它使他们变得炫酷。其他开发者恨它，它纯粹的炒作，他们说：它只是像以前来了新技术一样，我不明白为什么每个人都在谈论这件技术，他们说，通常的原因是，比理性更感性的。

鉴于Docker基于该技术本身不是必须的。大多的讨厌者是不是真的反应基于Docker解决方案的重要和复杂问题。大多数情况下，如果你没有花时间扩展系统，你可能没有注意到那些问题。如果不直观和深刻领会什么叫“黄牛不是宠物”，这确实很重要，那么你在选择很多由Docker和其相关工具会显得怪异和可怕。

合并世界

Docker正出于两个学科合并点：Web应用和分布式系统。在过去的十年中，我们所处的网络社区被大大假装成基本上都被我们可以通过了解如何编写代码构建Web应用程序。我们写一些HTML、JavaScript、Rails并且我们有一个网站。我们增加了一些forms、handlers，也许再加一个API，我们就大功告成了：这足够推出的一款产品，能够获得投资、客户和收入，可以改变世界！

同时，在过去的二十年中，分布式系统的那些人脉一直在做一些很无聊的破事。他们已经实验过像CORBA和SOAP复杂的协议，并学会如何解决问题，如CAP定理，以及证明为何时钟同步是不可能的，而这两大问题，以主要理论为居多。而这些问题及其解决方案对于只是试图拿用它来运送web应用程序的知识后续自己可以如何编写的那些人是无趣的。

但随后有趣的事情发生了。Web应用程序变得足够大，他们开始需要扩展。供多人访问该Web应用程序在一个VPS上再也呆不住，或者只是进行垂直扩展。当我们开始扩展，我们开始看到所有这些BUG在我们的应用中，存在有趣名字的漏洞，如“race conditions”、“network partitions”、“deadlock“和“Byzantine failures”。这些都是分布式系统兄弟们一直在努力一段时间去解决的问题，这些问题的解决方案不仅是困难，但在许多情况下，从理论上来说是不可能被解决的。

早年这种可扩展性的危机，随着Heroku的出现。况且Heroku让横向扩展基础设施变得容易了，使我们能够再次假装我们真的只是进行简单的Web应用程序。我们收买了自己内心，作为一个行业，也许是5年假装和自欺欺人。

我们现在打破自欺欺人的限制，就如我们从这个困局出来吧，我们发现自己试图在早期建立可扩展性，并重新这些破事做设计，使他们能够扩展，并了解整体架构的缺点正如为什么用一个单一的数据库是没有办法不停为我们工作。我们拿出像永恒建筑的短语，“宠物VS牛”，微服务，以及一整套的最佳和最差的实践方案使得这些事显得更容易。

在这一点上，这个转变过程中，Docker的到来，试图解决很多问题。但是，而不是告诉我们，我们可以假装扩展的问题不存在，我们可以以基本同样的方式继续做事情，像Heroku的那样，Docker告诉我们，分布式系统基本上是我们一直在做，一直以来，我们需要接受它，并一开始就在这个模型内进行编码。代替处理像web框架，数据库和操作系统简单的事情，我们现在看到类似Swarm、Weave、 Kubernetes 、etcd这类工具，这些工具不会假装一切都会变得简单，而实际上要求我们加紧我们研究，不单单是解决问题，而是要深刻理解，那些我们正在解决的问题。

有利的一面是，我们获得了建立可扩展架构的能力使得我们不会假装我们可以想象它并不存在。现在，我们需要知道什么是network partition，如何处理它，如何在一个AP和一个CP系统作出选择，以及如何构建架构：在实际恶劣的网络和机器下进行扩展。有时有雷电天气在弗吉尼亚州，有时候遇到了着火，有时鲨鱼咬伤海底电缆，有时还有延迟，递送失败的情况，机器挂了和内存泄漏。

一切都需要更加有弹性，更加可靠，而且我们需要承认，这些都是我们需要考虑的是开发应用程序的一部分。而我们需要做的，不是因为它的绚丽，或者因为它的一些神话般的最佳实践，而是因为像Amazon、Netflix、Google 已经把15年的汗水和鲜血和行业经验融入工作的人们把这些问题克服了，告诉我们如何在真正地大规模构建系统。

解决了实际问题

那么究竟是Docker为我们解决什么呢？我们正在做构建Web应用程序的一切是非常脆弱的，Docker是迫使这些变得合理化：

• 迄今为止，我们单独地部署应用程序（dev的一部分）在服务器（DevOps中ops那部分）上。而且，我们甚至有两个不同的团队管理这些应用程序栈。这样做是可笑的，因为应用程序依赖于机器和操作系统就如代码一样，并把它们分开考虑是没有意义的。集装箱会统一操作系统和应用程序在开发工具包中。
• 迄今为止，我们已经运行我们的面向服务架构在AWS 、Heroku、其他IaaSes和PaaSes ，它们缺乏任何合理的工具去迁移和管理面向服务架构。 Kubernetes和Swarm可以管理和协调这些服务。
• 迄今为止，我们已经使用了整个操作系统部署我们的应用程序，它们带来所有保障，而不是我们可以部署在最小化上。容器允许你暴露一个很小的仅需要端口的应用，甚至可以小到一个简单的静态二进制。
• 迄今为止，我们一直在摆弄机器，已确保它们是否是活着的，使用“配置管理”工具或者重新部署多次应用程序在同一台机器。由于容器可伸缩了业务流程框架，只有不变的镜像被启动且运行的机器都不会被重用，这样消除潜在的故障点。
• 迄今为止，随着像Rails的面向服务架构的路由规则的出现,我们使用的语言和框架，它们很大程度上被设计成单机单应用运行了。现在Kubernetes和Compose允许你指定跨服务的拓扑结构。
• 迄今为止，我们已经AWS给定的服务器配置搭配中部署重度依赖虚拟化服务。“我想要的是0.1个CPU和200MB的RAM服务器”，这个是不可能的。我们已经浪费了远比使用我们应用实际需要的虚拟化开销。容器可以按更小的配置进行部署，并做到更好的共享。
• 迄今为止，我们已经部署使用多用户操作系统的应用程序和服务。UNIX建有几十个同时在其上运行的用户，共享的二进制文件、数据库、文件系统和服务。这是一个完全不匹配当我们构建Web服务我们所做的。此外，容器可以容纳只是简单的二进制文件，而不是整个操作系统，这将导致除了关于你的应用程序或服务你可以少考虑。

唯一不变的就是变化

我们的行业不会等待这些技术的成熟，才如此迅速去神化令人振奋的新技术。Docker正在以惊人的速度发展，同样这意味着它没有接近稳定或成熟。我们在容器运行时间、镜像格式、流程控制工具、主机操作系统有很多种选择，每个都有不同程度的用途，范围，同样需要扶持和社区的支持。

环顾我们行业发展，存在很多直到技术成为老而乏味还没有得到稳定。举一个例子，有多少协议在我们得到了REST之前死去？我们用之前学到的教训建立了REST、AJAX、JSON协议是踩在了SOAP和CORBA的尸体上。这两个主要技术过渡过了大约10年的历程。然而，我们仍然没有得到在十年前有对SOAP等同的基于REST的API工具，并且尤其是还SOAP没有完全死亡。

同样的故事发生在前端，而且确实很多兄弟会拿前端开发正在做的蠢事与我的 Docker生态系统作对比。自从我们十年前逃离Java，同样的故事已经发生在各种编程语言中。自始自终，直到问题都完美解决，开发者会不断拿出新的解决方案。更何况Docker生态系统有成吨的问题需要解决。

因此我们可以预期 Docker目前是不会达到成熟的状态。当你尝试的时候，仍然有许多衍生和奇怪的问题需要你去打破，当从几年后我们回首它们，然而一些决定不止是无法让人理解，实际上可能是完全错误的。最好的做法还是要尝试、失败，重试、再失败，直到我们可以灵活运用它们。

这将花费数年，我们才能领悟这一切，并让它平息下来。但是，这并不意味着容器是废物，或者说我们可以忽略它们。我们总是在过往我们熟知的技术与进行飞跃，并尝试新的东西，从教训中学习、调整、迭代，并提高行业实力面临抉择。