本篇内容是根据2017年5月份#47 Docker, Moby, Containers音频录制内容的整理与翻译
Solomon Hykes 参加了节目，谈论了 Docker、Moby 项目以及 Go 非常适合容器管理的所有内容。
过程中为符合中文惯用表达有适当删改, 版权归原作者所有.
Erik St. Martin: 好的，大家好，欢迎回到 GoTime 的另一期节目。今天是第 47 期，我们的赞助商是 Toptal。今天的嘉宾包括我自己，Erik St. Martin，还有 Carlisia Pinto --- 打个招呼吧，Carlisia。
Carlisia Thompson: 大家好。
Erik St. Martin: 今天代替 Brian 出场的是 Adam Stacoviak。
Adam Stacoviak: 大家好！
Erik St. Martin: 能让你从幕后走出来，真的太好了。对于没听过 Adam 另一期节目的朋友来说，Adam 是我们的制作人之一，他总是躲在幕后；我们终于让他走出来了。
Adam Stacoviak: 没错......就像一个魔术师，等待着合适的时机偶尔露面......而 Solomon！我必须为 Solomon 出场，这就是原因。
Erik St. Martin: 说到这里......今天我们非常荣幸地邀请到了特别嘉宾，Docker 的 CTO 和创始人 Solomon Hykes。
Solomon Hykes: 大家好！感谢邀请我。
Adam Stacoviak: Solomon，非常感谢你抽出时间参加节目；虽然安排上有些波折，但我们一直在期待这次节目。 Docker 是一个巨大的项目，显然每个人都在深入了解它并不断探索。
我们在 Changelog 的节目中早在第 89 期就采访过你。当时用你自己的话来说，那好像是 20 年前的事了，感觉像是很久以前了......你怎么看？
Solomon Hykes: 是啊，感觉确实很久以前了，我对那次对话有很美好的记忆；那次节目非常有趣。
Adam Stacoviak: 给正在收听直播的听众，我会在聊天中放上 链接，大家可以标记一下。链接也会出现在节目笔记中，记得去看看......听听我以前（他们说的）年轻的声音，那时的 Adam，哈哈......
Erik St. Martin: 他今天在我们管理频道里分享了那期节目，我开始听......哇，你的声音真的听起来很年轻。 [笑声]
Adam Stacoviak: 或许是因为当时的音效调节不够？我也不知道......其实我也不确定。但总之......Docker！它是从 DotCloud 开始的，对吧？
Solomon Hykes: 是的。
Adam Stacoviak: 当时的 DotCloud 是什么？或许人们不需要太多你的介绍，但至少需要了解你今天的身份---你是 Docker 的 CTO 和创始人......带我们回到 DotCloud 的时代吧。给我们一些怀旧的回忆，有什么只有你知道的可以在节目里分享的？
Solomon Hykes: 好的......我不知道是否只有我知道，但当我们做那期 Changelog（第 89 期）的时候，我是一个名叫 DotCloud 的公司的创始人兼 CEO，后来这家公司成为了 Docker。当时我们刚刚发布了 Docker 项目，但还没有完全转型为只支持 Docker 的公司，虽然我觉得那已经很快就要发生了。但在 Docker 之前，还有六年的 DotCloud 时光。所以总的来说，我已经在这个公司工作了九年多了，DotCloud 是一个平台即服务（PaaS）的产品。如果你熟悉 Heroku 或 Google App Engine，类似的产品......它是一个托管服务，开发者可以用它来部署和扩展他们的应用。
基本上，你写代码，把代码交给我们，然后其他一切我们来处理。我们负责扩展、运行等等。我们在底层使用容器来提高效率。很多人问我们，"哇，这个技术真酷。你是怎么做到的？我不想付费使用你们的服务，但我想自己实现这个技术。"
Erik St. Martin: 人们想要免费用东西？[笑声]
Solomon Hykes: 是啊，真不可思议（笑）。其实，我们并没有发明这种技术；我们是基于底层的系统构建的。当时 Linux 正在逐渐改进对容器的支持，但这仍然是一个非常小众的技术。当我们在 2008 年开始时，你必须对内核进行大量修改，所以只能用于非常小众的场景。然后在 2012 到 2013 年左右，你可以在未修改的 Linux 内核上自己运行容器，这让很多事情成为了可能。
总之，我们听到了足够多的需求，最终决定开源底层技术，这就成了 Docker。当然，为什么它会流行起来，这仍然是一个结合了神秘、运气和（从我的角度看）努力工作的结果。后来我们卖掉了 PaaS 业务，只专注于 Docker。
Erik St. Martin: 你提到有点惊讶它会如此受欢迎......但该给的功劳还是要给，对吧？是的，Linux 内核里有容器功能，但我觉得 Docker 让它变得更容易接近了，对吗？大多数为 Linux 开发软件的人并不了解或者不熟悉 cgroups 和 namespaces。我觉得 Docker 真的让这些变得更容易接触，而且还有这种便携的镜像格式......
Solomon Hykes: 是的，实际上......有趣的是，Linux 容器本身就已经存在而且为人所知，尽管它只被一小部分专业人士知道，比如系统工程师和运维人员---他们会基于这些构建平台。但你说得对，这是一种非常晦涩的技术，老实说，当时它还不够成熟。Linux 容器在那时并没有稳定到高质量的程度......但实际上，我们利用了"容器"这个词的双重含义。Linux 容器是一个非常具体的技术概念，用来沙盒化你的运行应用......但我们将这个术语扩展到了类似"运输集装箱"的含义，后者完全是另一回事。它更多的是关于如何移动东西、如何使它们可重复使用以及如何标准化移动的格式。
直到今天，我觉得不同的人对"容器"这个词的理解是不同的。第一个定义是一个非常专业和小众的定义，而运输集装箱是一个所有人都能理解的主流术语，这实际上也是 Docker 专注的领域。
对于 Docker 来说，Linux 容器只是我们用来交付更广泛功能的一个特性，而这个更广泛的功能是为你的代码提供"运输集装箱"。
Erik St. Martin: 我这里有一个有趣的问题，想听听你的看法......我发现虚拟机（VM）和容器之间的区别在于，Docker 因为很好地抽象了概念，所以人们常常会混淆它们很相似。很多人会把 tcpdump 和其他随机工具放进容器里，然后加载它们，因为他们没有真正理解容器更接近于一个高度配置的进程，而不是一个真正的虚拟机。你觉得人们也有类似的困惑吗？
Solomon Hykes: 是的，对于我们来说，有一个普遍的主题，那就是不同的人对 Docker 或容器有着不同的理解或体验，他们有着不同的看法。Docker 社区一直以来都非常多元化。换句话说，不同的人对容器和 Docker 有着不同的期望，有时候甚至会对什么才是正确的答案产生激烈的分歧。
对我们来说，管理这种情况一直是一个挑战。但老实说，这从一开始就是我们的设计初衷：我们说，"你知道吗？并不是每个人都需要对所有事情达成一致才能从同样的工具中受益。" 或许让人们在不同的定义中找到共同点会让事情变得更有趣，那种建设性的分歧会推动我们前进......而且我认为大部分情况下，这是有效的。
举个例子，Docker 社区中有很多开发者和运维人员。我们都知道，开发者和运维人员在事情上的优先级和看法是非常不同的，而这种差异反而带来了好处。一方面，有 Linux 专家、系统工程师等专业人士，他们以一种方式看待容器；另一方面，现在有很多前端开发者刚刚开始接触后端，Docker 对他们来说是一种非常简单的方式去处理后端事务。如今，还有一些完全初学编程的人，Docker 为他们提供了一个安全、有趣的起点，让他们不会感到被评判，并且身边有一群乐于帮助他们的人。
这些是两个非常极端的群体，但挑战在于："我们如何让所有人都参与到同一个社区中，一起讨论容器？" 这并不总是容易的。
Erik St. Martin: 这是一个非常有趣的观点，我之前从未考虑过。
Carlisia Thompson: Solomon，我想请你回顾一下从平台即服务（PaaS）转型为开源项目的那个阶段......因为我在想---毫无疑问，你们现在是一个成功的案例，这让一切变得更加引人入胜......所以我在想，你有一个按使用付费的服务，人们也在使用你的服务，但他们却说"我们不想为此付费"。我从一个商业视角来问这个问题，特别是对于那些想创业或正在创业的人......我自己也会有这个问题，我想大家也会很好奇，所以我们来聊聊这个吧。
当时你们处于这样一个阶段：人们在使用你的服务，但他们不想为此付费。那么，你们是如何做出这样的决定，而不是说，"我们调整一下定价模式"或者"我们提供更好的服务，让人们觉得他们的花费物有所值，从而愿意付费"？对我来说，这似乎是一个非常反直觉的决定---"不如把它提取出来，作为一个开源项目提供。" 这种转变是怎么发生的？你们当时有一个明确的计划吗？这个过程是怎样的？
Solomon Hykes: 这是个好问题。并不是说人们不想为我们的服务付费，我们就放弃了这个服务......实际上，DotCloud 这个产品还是挺成功的；我们有客户，我们在稳步增长，也确实有一部分客户从中得到了价值。而且我们并没有遇到紧急危机。当时我们账户里有足够的钱......我记得我们还有两年的资金储备，所以这不是一个资金问题，也不是"没人想要这个产品，他们不想付费"的问题。但我们确实有两个问题：一是潜在客户的市场规模太小，我们看到其他同样面对这个市场的公司都不太成功。基本上，每一家平台即服务的初创公司都失败了。
有些公司通过并入更大的公司而避免了失败，这对它们来说是很好的选择。但显然，没有一家非常成功的大型平台即服务公司可以让你指着它说："我想和他们竞争。" 所以我们普遍觉得，我们所在的市场没有未来。同时，我们看到了一个更大的人群，他们来找我们说："我们想从你们这里得到一些东西，可以给我们吗？" 他们并不想要免费使用我们的服务，而是想要别的东西；他们想要的是构建自己服务的基本模块，关键在于定制化。
当你为客户提供一切时，问题在于这是一个一刀切的解决方案；你有一个单一的、整体的平台，它为你做了所有事情，要么接受，要么放弃。这确实很方便，但如果你想要定制化，就做不到；你只能离开，或者等待 DotCloud 添加这种定制化功能。而有了容器，你就像有了一个乐高积木套装。你可以混搭，可以改变很多东西，只需要有这些基础模块可用。
我经常举的一个例子是普通玩具和乐高的对比。我们当时有一个特定的玩具，一些人喜欢，但更多的人说："嘿，我能不能改一下这个或者那个？你能不能让我自己造一个玩具？只要给我乐高就行了。" 所以我们开始在旁边做一些实验。我们做了一个副项目---也就是后来成为 Docker 的项目---来看看如果我们给人们提供"乐高"会是什么样子。结果是立竿见影的。从我们第一次在内部做私下演示开始，大约是在推出 Docker 的前四个月，人们就已经非常兴奋了。大家表现出了巨大的兴趣，所以我们只是顺应了这种兴趣。
最终，大家对新事物的兴趣超过了对旧事物的兴趣，于是我们做出了决定。在你的问题中提到的"跃进"，发生在我们有两个都可行的选择时，这也是为什么这个决定很难。如果 DotCloud 明显失败了，这反而会是一个更容易做出的决定，因为那时候根本没有选择。但因为 DotCloud 并没有明显失败，我们不得不做出决定。实际上，我一开始说："我们两个都做。DotCloud 是我们的第一阶段，这个令人兴奋的新东西是第二阶段。" 我们还画了一个图表，第一条增长曲线最终会被第二条增长曲线取代......理论上很棒，但实际操作中，很快我们就发现必须专注。虽然是个艰难的决定，但我们选择了新事物。
Adam Stacoviak: 我本以为你会说，Docker 显然是一个更大的发展方向，我以为你会这么说。
Solomon Hykes: 嗯，这确实是我们最终得出的结论......
Adam Stacoviak: 嗯......
Solomon Hykes: ......所以我们才迈出了这一步，但在当时，这一点完全不明显。
Adam Stacoviak: 那时候很难看清。
Solomon Hykes: 我们是在......你知道 PyCon 上的那个 lightning talk 两周后转型的。
Adam Stacoviak: 2013 年。
Solomon Hykes: 是的，2013 年，Docker 被介绍出来......
Adam Stacoviak: 那是你第一次谈论关于 Linux 容器未来的演讲，对吧？那就是 Docker。
Solomon Hykes: 是的。
Adam Stacoviak: 然后它就火了。
Solomon Hykes: 那成了我们"意外的发布会"，因为我们并没有计划把那作为我们的发布会。这里还有一个有趣的故事，但重点是，我想我们发布后几周内转型了。所以这一切都发生在......
Adam Stacoviak: 很快，因为当时你上 Changelog 的时候，你还在讨论 DotCloud......实际上，那场演讲---我们会把它的链接放在节目笔记里供听众参考。我会把链接发到 Slack 频道里。那场演讲，当时 Andrew Thorp（当时是 Changelog 的联合主持人）和我看了之后，我们觉得："这个东西超酷。这正在获得关注。" 到今天为止，这场演讲已经有将近 7 万次观看量了，而在开发者领域，这已经是很高的观看量了。也许在整个 YouTube 世界，百万或几百万才算大，但在开发者领域，这个数字已经很大了。
Solomon Hykes: 嗯，如果我想成为 YouTube 明星的话，我还有很多工作要做。
Adam Stacoviak: 没错......我们正在努力。
Erik St. Martin: 我记得第一次看到 Docker 的时候，它还是 DotCloud。Brian 和我当时在玩这个东西，我们就有一种感觉：这东西会成大事。它改变了一切。我记得---可能是在 Changelog 的那期节目里---Solomon 提到了虚拟机以及人们对它的期待，但它并没有真正实现。虽然有一些工具让虚拟机在开发中变得有用，比如 Vagrant，但它们的效果远远没达到 Docker 在可复现性和启动速度上的水平。
Adam Stacoviak: 那么 Go 在这其中扮演了什么角色呢？毕竟这是 GoTime，对吧？Go 在 Docker 中的作用是什么？
Carlisia Thompson: 我能问一个关于 Docker 故事之前的问题吗？你们在 DotCloud 用过 Go 吗？
Solomon Hykes: 这是个好问题。答案是没有，我们当时没有用 Go。我们是一个 Python 的团队，所以我们才会在 PyCon 上做展示。
Adam Stacoviak: 这就说得通了。
Solomon Hykes: DotCloud 是用 Python 写的，尽管它可以运行各种类型、用各种语言编写的应用程序---顺便说一下，这是我们的差异化优势---因为我们使用了容器，所以我们为所有语言的应用程序提供了一个通用的打包和部署系统。现在这听起来像是理所当然的，但在当时，这是一个大事，没有人这么做......当我们开始开发后来成为 Docker 的这个原型项目时，最初的版本也是用 Python 写的。
后来，我们迭代了几次......但产品始终不是很对路。与此同时，我对这个项目的设计有非常强烈的意见，结果就是，我把团队里的核心工程师逼得受不了，他离开了......我们不得不从头开始。也就是在那时，我们做出了一个重要的决定：转向使用 Go。
这个决定更多是出于直觉，而不是深思熟虑的。老实说，当时这个决定在 DotCloud 内部并不受欢迎......但主要基于几个原因：首先，我直觉上觉得 Go 很棒，我也想尝试一下，说实话就是这样......当然，也有一些理性的考量。
第一，我们希望优化项目的贡献度。我们希望这个开源项目非常成功，希望有很多人来参与贡献。所以我们需要一个容易上手、对更多人来说熟悉的语言，同时又不能太极端或有太强的主观倾向。我对技术宗教战争没什么兴趣，我觉得很无聊，我尽量远离这些东西。我喜欢 Go 的原因是：如果你是一个 C 程序员，你会觉得"好吧，我能看懂"；如果你是一个 Python 程序员---也是一样。这种熟悉感足够吸引更多人，让我们能够快速建立一个主流的贡献者群体，这是一个很大的动力。
另一个原因是，在运维和 DevOps 工具领域，最大的问题长期以来是部落分裂。你有 Python 的 DevOps 工具，也有 Ruby 的 DevOps 工具，还有 Java 的 DevOps 工具。当时，这三大阵营是主流。而无论你为你的工具选择了哪种语言，只有你所在的阵营会使用它。其他阵营会直接复制一个类似的工具，导致每件事情都有完全冗余的工具。比如 Fabric 和......你知道吗？我甚至不记得这些工具的名字了......Capistrano。
Erik St. Martin: 哦，我记得 Capistrano。 (译者注: 很古老的一个Ruby写的服务部署工具)
Solomon Hykes: Java 当时也有自己的工具......所有东西都是重复造轮子。而我们希望打造一个所有人都能使用的工具，所以我们需要一种可以编译成二进制文件的语言。就像早期 UNIX 守护进程（daemon）那样，比如 SSHD......谁会关心它是用哪种语言写的？它是一个二进制文件，你放在那里，它就能运行，对吧？所以这跟易用性有关，我们不想让用户必须额外安装运行时环境。
所有这些因素加在一起，我们最终全力投入了 Go。Docker 是我第一个用 Go 写的项目，显然这个选择很正确。我们确实搭上了 Go 普及的浪潮，同时也为它做出了贡献。这就是我们选择 Go 的原因。
Adam Stacoviak: 说到这儿，Erik，你提到你最近参加了一个聚会，你们讨论过这个话题......Solomon 提到的这些问题，比如 Ruby 可能因为 Ruby on Rails 很流行---Matz 自己也这么说过。你觉得 Go 的流行是因为像 Docker 或其他超级流行的项目，比如 Kubernetes 这样的东西吗？我猜 Kubernetes 可以算是 Docker 的进化版，但你懂我的意思。那次聚会里是怎么说的？
Erik St. Martin: 我们主要讨论了 Go 的普及曲线。Solomon，你刚刚提到你选择 Go 是因为想要更多贡献者......但当时，Go 1.0 刚发布可能还不到一年。我觉得 2014 到 2015 年是 Go 语言开始"曲线爆发"的时期。我认为 Docker 对此起了很大的作用。比如，"这是一个能彻底改变开发和运维方式的东西。这真的会改变一切。" 人们对它的实现方式很感兴趣，他们想构建它，想为它贡献代码，我觉得这吸引了更多人去了解 Go 语言。
所以我觉得那一年是一场"完美风暴"。各种会议开始涌现，你有 Docker，还有......
Solomon Hykes: 是的，我们决定用 Go 的时间是在 2012 年底。
Adam Stacoviak: 那很早。
Erik St. Martin: 也就是说，1.0 发布后一个月左右。
Solomon Hykes: 当时，这个选择并不是显而易见的---它并没有被炒作，我们没有听到什么"哦，我们必须赶快加入这个潮流"的声音。更多的是，"嘿，我对这个很感兴趣，我内心的黑客精神驱使着我......" 有时候，你会被某个工具或语言吸引，然后在之后才找出一些理性的理由来为你的选择辩护...... 这就是我对 Go 的感觉。而作为创业者，我想，"如果我有这样的感觉，那么我的目标用户---那些和我一样的黑客们、我希望他们使用我的工具的人---可能也会有同样的感觉，所以不如跟着这种直觉走，顺势而为。" 结果证明我是对的。
Adam Stacoviak: 离我们第一个中场休息---或者说是这次节目中唯一的休息---还有大约六分钟。带我们回到你做出这个选择内部争论的场景吧。明确一点，这是你为 Docker 的未来选择 Go 而非 Python 的决定，对吗？
Solomon Hykes: 是的。
Adam Stacoviak: 那么，在这个过程中，你是如何向团队推销这个决定的？特别是因为你们在转型，而且赌注很高...... 成功的压力很大。你是怎么让大家接受这个决定的？
Solomon Hykes: 首先，到 2012 年底，我们还没有真正开始转型，对吧？要说明的是，当时我们公司大概有 20 人，其中 18 个人都在做 DotCloud。然后是我和另外一个工程师在做这个副项目。所以在内部，这个项目有一段时间被看作是"Solomon 的宠物项目"。大家认为，"他想继续写代码，那就让他写吧......"
Adam Stacoviak: "...让他搞他的东西。"
Solomon Hykes: "...让他搞他的事情，就这样。" 所以当我说，"嘿，我们用 Go 来做这个吧"，最大的反对意见（[音频不清晰 00:23:11.08]）是觉得它太新了，而且没必要为了新而改变。所以有点像那种"滚开，别搞这些花哨的新潮玩意儿！"的反应。而这里我想澄清一点，这对很多人来说可能很意外，因为现在 Docker 有点成为了"新潮开发者工具"的代名词，这让我觉得很搞笑。其实 DotCloud 是一家运维驱动的公司。我想我们曾经运行着世界上最大的公开部署的 Linux 容器集群；当然，Google 有他们自己的东西，但如果你想部署容器，我们运行着最大的生产环境的 Linux 容器集群。所以我们是一个运维团队，我们在容器中运行数据库、各种语言栈......
Docker 是从实际的运维经验中诞生的。当然后来，它被一个非常兴奋的开发者社区所接受，我们不得不管理社区中多样化的意见和需求（我们之前提到过）。但重点是，在 2012 年，我们绝对是一个对任何新东西都充满怀疑的"老派"运维团队，因为新东西会坏掉，新东西有时只是为了追逐潮流。所以最大的反对声音是"又来玩新玩具了"...... 但最终大家还是觉得，"嘿，反正这是 Solomon 的玩具项目，就让他玩吧。"
Adam Stacoviak: 哇...... 所以基本上你是靠自己是"老板"这个身份来推动这件事的，用"他喜欢折腾，就让他折腾吧"这样的方式。
Solomon Hykes: 事情是这样的，其实我不需要去说服谁，因为那个被借调来帮我做这个副项目的工程师辞职了......
Adam Stacoviak: ......所以根本没人反对。
Solomon Hykes: 就只剩下我一个人...... [笑声] 后来我找了另一个工程师---Andrea，他现在仍然是 Docker 的明星工程师。他负责写硬件系统接口...... 他写了 LXC 的接口，而我则负责写 UI，也就是前端部分。
Adam Stacoviak: 一开始 Go 的哪些特性吸引了你？其实我想问的是，有什么具体原因让你选择 Go？你提到过编译为二进制文件可以减少麻烦之类的，但还有什么？
Solomon Hykes: 这些是外部原因，具体来说是为什么 Go 适合这个项目（Docker）。但从一个黑客的角度来说，吸引我本能地选择 Go 的原因是---我受过 C 系统工程师的训练，后来转用 Python，因为有段时间用 C 做所有事情实在太浪费时间了。从 Python 开始，我们用上了一个非常酷的框架，我甚至不记得它叫什么了......好像叫 gevent？对，就是轻量级线程，也叫绿线程。所以用 Python 加上 gevent 或者 greenlet（我忘记具体名字了），你可以用一种类似 Go 和 goroutines 的范式写代码。你可以用过程化的风格写代码，同时获得类似回调的好处，但又不会陷入回调地狱和代码混乱的困境，而当时 Python 的另一种方式就是 twisted。
在 DotCloud，我们所有事情都用 Python 加 gevent 来做，但有时候我们会后悔没有更简单的方法来利用 C。然后 Go 出现了。从一个用 Python 的 C 黑客的角度来看，Go 是两者的完美结合。它拥有 C 的所有优点---编译型语言、轻量级、对内存的细粒度控制等等，同时也有像 Python 那样方便的高级语法，还有一个优秀的标准库。Python 开发者已经习惯了依赖高质量的标准库，而 Go 也提供了同样的东西。这和 Ruby 不一样，我的经验是 Ruby 就像一个巨大的实验性集合，你永远不知道它什么时候会崩溃。
我觉得 Go 早期就带来了那种对高质量、可靠的标准库的专注，这真的戳中了我的所有点。
Erik St. Martin: 我知道我们已经超过 Adam 之前提到的休息时间了，他总是很注意时间的。所以我们现在进入本期节目的赞助商休息时间。今天的赞助商是 Toptal。
休息时间：
Erik St. Martin: 好的，我们回来了，继续和 Solomon Hykes 聊天。Carlisia，我记得在休息前你对 Adam 的问题有一个后续问题......你现在想继续问吗？
Carlisia Thompson: 是的，Adam 提了一个很好的问题，但我觉得我们还没有得到答案。他问的是："Docker 对 Go 的流行有什么影响？"这个问题有被回答吗？
Adam Stacoviak: 我不确定，我想他当时讲到了一些 [音频不清晰 00:28:43.01] 和 Go 的特性，虽然我很想听听这个问题的答案。比如我们常听到像 Matz（Ruby 的创造者）谈论 Ruby on Rails 对 Ruby 的影响......而你，Solomon，作为 2012 年早期选择 Go 来做 Docker 的人，你觉得 Docker 对 Go 语言有什么影响？
Solomon Hykes: 我偶尔会问自己这个问题，但说实话，我并不完全清楚。我的感觉是，Docker 早期使用 Go 的确起到了验证 Go 的作用，在 Go 明显开始流行但仍需要一些大型项目来证明其实用性的阶段，这种验证尤其重要。我觉得在某些时候，我们可能是当时最大的 Go 项目，尽管我不确定今天是否还如此......但现在的重点是，Go 已经不再需要这样的证明了。
我觉得现在我们只是 Go 生态中的一员，我们以这种方式做出贡献，但 Go 已经不再处于需要通过特定项目来证明自己价值的阶段。我认为它现在是一门主流语言了，这真是太棒了。
Erik St. Martin: 这很有趣，因为在差不多同一时间，Brian 和我在筹备第一届 GopherCon 时也有类似的想法。我们不想把会议安排在旧金山，这也是为了证明这不仅仅是 Google 的语言，而是一个超越 Google 的东西。所以那一年我们基本上都在为语言辩护，像是"不是的，不只是 Google 在用 Go 写东西。"
Solomon Hykes: 是的，我记得我们其实也经历了类似的过程......我们做了一点尽职调查。就像我说的，我是发自内心地决定使用 Go，然后假装自己是在通过正式的理智决策过程。我记得我们当时寻找了一些证明点，但确实找不到什么高知名度的、在 Google 外部使用 Go 的成熟且大型项目。不过我记得有一点让我下定决心，那就是在 Google 内部---当时还不清楚 Google 其实在生产环境中用了多少 Go，但我记得有一次 Google 的博客上发了一篇文章，提到......我忘了那个服务的名字，但它是 Google 的一个定制 MySQL 前端......
Erik St. Martin: Vitesse。 (译者注: 实际是 vitess)
Solomon Hykes: 是的，没错......我想他们后来开源了，但当时还没有开源。不过他们在博客中提到这个服务是用 Go 写的，而且说整个 YouTube.com 前端的 MySQL 查询关键路径都通过了这个服务。我当时简单地在脑海里算了一下，觉得"好吧，我可以用这门语言。"
Adam Stacoviak: 很棒。
Solomon Hykes: 所以那是当时让我信服的点。
Erik St. Martin: 是的，我记得尝试运行 Vitesse......真的非常酷。我们现在有点在聊过去的回忆，我想逐步转到 Docker 的成长以及它现在的状态。但我有一个问题是，既然你们这么早就开始采用 Go，甚至到现在，当时 Go 的标准库和周边工具并不多，而采用新语言的一部分成本就是不得不自己写很多东西......在这个决策过程中，你们遇到了哪些绊脚石？
Solomon Hykes: 没有什么特别大的问题。我们遇到过很多战术上的问题，尤其是在第二年，当我们开始真正深入到系统层面的时候。Docker 的特点是，在早期，它是一个基于现有命令行工具 LXC 的封装工具。实际上，开发 Docker 的一个动机就是因为 LXC 的命令行工具完全不可靠，在运维中会出现各种可怕的不一致性。比如，同一个命令有时会失败然后返回，有时会直接挂起且永远不返回......根本无法预测结果。因此我们需要在其上构建一个稳定可靠的层......顺便说一句，现在我们常听到一些"古板的人"（姑且这么称呼吧）说："哦，Docker，只是个潮流工具......LXC 才是真正的'硬核工具'。" [笑] 但我可以告诉你们，作为运行了几百万个基于 LXC 容器的生产环境的人，与那些"古板的人"不同，用 LXC 并不有趣。
重点是，因为我们做的是封装，所以早期并不需要太复杂的系统交互。我们基本上是调用 LXC 的命令行工具，然后解析它的输出，类似这种方式。所以我们并没有真正触及标准库的极限......当然，我们也遇到过 bug、不稳定和性能问题，但没有什么特别值得记住的。
到了第二年，当我们替换掉 LXC 并实现了一个直接调用 Linux 内核功能的库，叫 LibContainer......在那时我们遇到了一些问题，但老实说，没有什么特别值得记住的实例。实际上，考虑到 Go 的采用率和成熟度，我一直对它的标准库的质量和广度印象深刻，尤其是相对于语言的成熟阶段。如果你理解我的意思的话，这真的是一个运行得非常好的项目，质量非常高。
我们一直在为 Docker 的最新版本采用 Go 的最新版本，从未落后过。我们从来没有想过"哦，让别人先经历痛苦，我们再升级。" Go 项目让我们学会了信任他们的最新稳定版本......顺便说一下，我希望我能说 Docker 从一开始就达到了同样的水平，但这花了一些时间。
Carlisia Thompson: 那现在呢？你们有没有一个明确的点，比如"现在使用标准库以外的现有库是合理的"？或者 Docker 或 Moby 有没有一个哲学，比如"我们不使用外部库，只用标准库，一切都自己写"？你们有这样的规则吗？如果没有，你们如何决定"现在值得使用一个外部库"？或者说你们是否有一些类别会考虑使用外部库，但其他类别不会？
Solomon Hykes: 首先，我听到你提到了"Moby"，那么稍后我可以针对这个问题做个说明吗？
Adam Stacoviak: 是的，我们很快会聊到这个话题。
Solomon Hykes: 回答你的问题，首先，我现在不太直接制定这些规则了......我们已经把这种决策权下放给了很多维护者，但我觉得我们一直遵循的是常识性的规则。如果标准库能实现，就用标准库；如果有外部库能实现，就检查它的更新情况、维护者的响应速度、使用的人数，如果感觉靠谱，那就用。
如果以上都不满足，那就自己写，但要小心别浪费太多时间。如果后来发现有很多人需要这个功能并最终使用了你的实现，那就尽早把它分离出来，变成一个独立的库，这样它就不会和你的项目绑定得太紧。
我觉得我们就是遵循了这些原则，但我觉得我刚才说的这些其实适用于任何 [音频不清晰 00:36:18.05] 软件项目。我们并没有做什么特别不同的事情。
Carlisia Thompson: 听起来很合理，是的。
Adam Stacoviak: 我们今天来到这里......现在已经差不多是四年以后了。Docker 很酷，大家都在用它......我们进入了一个全新的世界，在这个世界里，Docker 基本上就是容器领域的代名词。你们已经拥有了这个名称。如果你谈到容器，你基本上就会说 Docker，对吧？这就是我们现在所处的情况，甚至在命名事物时也是如此。Solomon，你提到了 GoTime FM 聊天室，所以如果你是在之后（不是直播时）收听这个节目，我们是每周四直播的，你可以在 GopherSlack 的 GoTime FM 频道和我们一起交流；我鼓励你加入，但如果你没加入，也没关系。不过在聊天中，我们讨论了 Docker 过渡到新名称 Moby 的事情。
新闻出来了---我猜大概是三周前，也许一个月前......我这段时间有点忙于自己的事情，不太确定具体时间线，但你们已经进入了一个新阶段，并且改变了这个非常知名的品牌名称 Docker/容器，而且......你怎么敢这样做？为什么会发生这种事情？[笑声] 我觉得这是大家的反应，至少在我看来是这样的......就像，"你为什么要这么做？" 你们内部的看法也是一样的吗？
Solomon Hykes: 是的......这确实是一个很大的改变，就像任何大的改变一样，它需要一段时间才能尘埃落定。这是一个真正渐进的改变；是一个持续的变化。只是某个时候你需要启动它，而 DockerCon 上个月就是我们启动它的时间点。
Adam Stacoviak: 好吧，那就是大约一个月前了。
Solomon Hykes: 是的，没错。所以在那个时间点之前我们进行了很多工作和逐步的改变，而在那个时间点之后也会有很多逐步的改变和工作，但我想对于很多人来说，这个公告当然是他们第一次听说这件事。关键是，这是一个根本性的转变，我们为此已经努力了很长时间，老实说，我觉得我们本可以在公告的一些战术方面处理得更好......但首先，我想先谈谈"大家"这个词，因为 Docker 的一个非常有趣的地方是---这要追溯到我们讨论的最初话题，"谁是 Docker 社区的一员？这个社区有多大？有多统一？有多样化？" 答案是："它非常非常大，也非常非常多样化"，我认为你可以从这次改变的反应和认知中看到这一点。
Docker 现在，一方面是一个开发者用来开发应用程序的平台，运维人员用来部署和管理应用程序的平台，我们可以在小型项目（业余爱好者）、小型企业中看到这一点，现在也可以在企业中看到。现在有一些非常大的组织，他们的开发者整天都在使用 Docker，运维人员也整天都在使用 Docker 来运行各种应用程序。这是 Docker 的一个方面，也是 Docker 社区的一个维度。
然后还有另一个方面，这是一个开源项目，专注且充满热情的黑客们一起在代码中协作，利用这些技术来做与容器相关的事情，对吧？容器运行时、容器网络、容器存储等等。我们有一个由系统黑客组成的开源社区。这个社区要小得多，也更加专业化。对我们来说，这个比例大约是 1 比 1000。
所以需要意识到的关键是，向 Moby 的切换对第二个群体，也就是开源贡献者社区，有积极的影响；这是目标。目标是改善开源社区的情况。
这对我们的用户社区或客户完全没有影响。或者说，如果有影响，也是间接的。换句话说，如果你从更大的范围来看这个社区---任何曾经访问过 github.com/docker/docker 的人都属于这一组群体，较小的群体，更专业、更了解内部工作原理的群体，他们实际上在参与创建它。
但对其他所有使用 Docker 的人来说，什么都没有改变。Docker 还是 Docker，仍然以同样的方式更新，它拥有相同的功能，相同的接口，相同的免费版本和付费版本......所以，为了给出背景，这是一个需要记住的重要维度。
Erik St. Martin: 所以我想这是一个关于认知的问题，也有点困惑......是的，我觉得很多人以为"哦，现在是 Moby 容器了，现在我要运行 Moby 命令了"，但你基本上是在说，如果你没有接触 Docker 的代码，你永远不会知道。如果你是一个 Node.js 开发者，你只是用 Docker 部署应用程序，你仍然在使用 Docker，你仍然会去 Docker.com 下载 RPM 文件或其他东西来安装它。
Solomon Hykes: 完全正确。我认为造成这种困惑的部分原因是我们没有很好地解释清楚。
Adam Stacoviak: 如果你不介意我这么说的话，这看起来像是---我不会说是太早发布，但看起来你们没有充分考虑到它的影响，也许......我不知道，这似乎有点像是被随意抛出来的。你觉得这是这样执行的吗？还是你觉得它没有被足够用心地处理？我没有负面的意思；只是觉得你们好像没有把它当成一件很重要的事。
Erik St. Martin: 我觉得当你离问题太近时，你不一定能看到外界人们的看法。所以，当你在这个项目上工作时，你会觉得，"哦，这完全说得通，我们在做 Moby；它基本上是 Docker 的上游。人们用 Docker，一切都很好......"
Adam Stacoviak: 这也是为什么我开场时提到 Docker 和 Xerox 的类比，因为在我看来---我相信在很多开发者看来也是如此---当你想到容器时，你就会想到 Docker。所以，当你对容器的品牌名称或这一运动（可以这么说）进行改动时，实际上是在搞乱容器的名字，这会让很多人不满。
Solomon Hykes: 是的，我觉得这是一个完全合理的问题。确实，我们在整个过程中投入了很多精力；我们中有很多人已经为这个改变努力了一年半时间......
Adam Stacoviak: 对。这看起来不像是你们会盲目去做的事情，考虑到你分享给我们的内容，这也是为什么我们从最初的怀旧情感开始聊起。你们在最初过渡到 Docker 时投入了很多心血，所以显然，在转向 Moby 时也会同样慎重。
Solomon Hykes: 我们确实很慎重，但我觉得我们在过程中犯了一些战术上的错误。整个过程本可以更顺畅一些。我不会深入讲整个背景故事，但我认为我们确实做出了一些错误的判断。从大局来看，这只是第一天，重要的是接下来会有多少贡献继续流入，项目的健康状况如何，Docker 产品的未来发展如何，有多少人会继续使用它，以及他们会有多满意，等等。
老实说，我觉得再过六个月回头看，这会像是雷达上的一个小点。关键是接下来的六个月里，我们执行得如何......我做过很多产品发布；没有任何一次发布是完全顺利的，总会有一些问题出现。就这次来说，我觉得出问题的地方---举几个细节或例子---是我们在沟通上极力优化了两个完全相反的群体。
我们花了很多时间与项目维护者沟通。这是一个非常小的群体---实际上只有不到 50 人拥有项目或其某个组件的提交权限。
我在公告发布前两个月就开始了一封电子邮件讨论，讨论 Docker 作为一个开源产品和 Docker 作为一个开源项目之间的矛盾......还有围绕这两个（产品和项目）的社区不同，它们有不同的期望，有不同的需求，而我们已经达到了一个规模，这种混淆变得成了问题。这封邮件中我们还讨论了 Red Hat 在 Fedora 和 Red Hat Enterprise Linux 分离上的做法......所以我们在这个讨论线上投入了很多精力，持续了两个月。
另一方面，我们也努力确保不会对我们的用户和客户造成干扰。任何使用 Docker 的人，我们都想确保他们不会受到影响，同时他们也能理解 Moby 的变化。所以我们花了很多时间为主流人群（我指的是我们的主流人群）设计一个可以理解的故事。你仍然需要是开发者，或者是了解并关心 Docker 的人，但你不需要是容器引擎的开源贡献者。我们花了很多时间思考如何以最佳方式解释这件事，因为这是一个复杂的话题。实际上，我们切换到 Moby 的根本是改变了我们的生产模式......
从使用 Docker 的人的角度来说，我们是在说，"嘿，我们正在改变 Docker 在底层的生产方式，如果你感兴趣，这里有一个高层次的解释，告诉你这对你意味着什么以及为什么这是件好事。" 我们为此进行了优化，这也是我们在 DockerCon 大会主旨演讲中讲述的故事。我认为如果你对这个话题感兴趣，可以去看看那个 主旨演讲（我想我们已经把它放到网上了）。这是第一天的主旨演讲，里面有很多图解......所以，这也是我们关注的另一个方向---向我们的主流用户社区很好地解释这件事。
我们做了这两件事，但我觉得我们犯的错误是低估了中间人群的反应。这个中间人群是许多访问我们 GitHub 仓库的人，他们在开源项目中有一些参与，但很浅层；他们不是活跃的提交者，也不是项目的管理者，但他们也不是那些从来没有看过 Docker 源代码的应用开发者。他们介于两者之间。老实说，我觉得对于这个中间社区，我们并没有准备好一份解释。
我们的计划是"让我们宣布我们的意图，把代码库搬到一个新地方，然后邀请社区一起来帮助我们执行这次更开放的变更，看看会发生什么。" 结果就是一段时间里，这个变化引起了极大的困惑和愤怒。
Adam Stacoviak: 这感觉就像是硬生生地撕掉了一个创可贴。
Solomon Hykes: 是的，我觉得是这样，但我们当时的希望是---再给一些背景......抱歉，我有点跑题了......
Adam Stacoviak: 没关系，没关系。
Solomon Hykes: 来自开源贡献者社区的很多批评---其中的一部分---是我们在某个时刻开始的行为更像是一个产品......Docker开始变得更像是一个公司驱动的产品，而不是一个社区驱动的项目。我谈到了这个冲突，即Docker作为项目和Docker作为产品之间的矛盾；这个话题我们与维护者进行了深入讨论，但之后却忘记与其他人讨论。
我们讨论的典型例子是Docker 1.12的发布，那个时候我们推出了内置的编排功能。这让很多贡献者非常生气，主要有两个原因。第一，我们没有提前警告他们；我们在Docker内部秘密开发了这个功能，然后才推出，这对于一个产品来说是典型的做法，但对于一个项目来说却并不常见。因此，这真的突显了项目和产品之间的差异。
人们生气的另一个原因是我们没有使用Kubernetes来实现这个功能。有一部分贡献者同时也在为Kubernetes贡献，他们是这个项目的忠实粉丝，他们对我们没有使用他们的项目感到非常愤怒......我们怎么敢？顺便说一下，我认为Kubernetes是一个很棒的项目。我们确实考虑过使用它，但最终决定不使用；这只是一个工程上的决定。
无论如何，我想说的是，因为我们受到如此多的批评，因在封闭的环境中做事情并在发布之前将其打磨得非常完美，我们想"嘿，关于Moby，我们就做相反的事。让我们做最小可行的改变"---就是将代码库从一个组织迁移到另一个组织---然后不做其他更改，再解释计划，然后与社区一起公开进行每个变更。这就是我们所做的，但却引发了相反的反响，即"这是什么？这很半成品。不清楚，发生了什么？"
我们认为通过将事情完全公开并让每个人参与来表现得非常友好，但实际上我觉得我们让很多人感到困惑。所以......
Adam Stacoviak: 但这也许是事实......我们的生产交付因为名称更改而中断了几天......我想聊天中有一个问题："为什么那么多人[听不清 00:49:59.06]"我觉得这可能只是docker/docker与moby/moby之间的区别......本质上是一个改变，这可能让很多人感到困惑。这个突如其来的变化就是我所说的......
Solomon Hykes: 实际上，真正出问题的事情非常少。我认为我们在重定向时出现了一个小故障，但基本上，所有出问题的东西都是轻微出错，并在当天修复。其他的主要是因为我们移动了代码库---从docker/docker到moby/moby。这让人看起来我们是将Docker产品更名为Moby产品。
Adam Stacoviak: 因此，才有Docker/Xerox的比较，因为"为什么要改变这个？"说实话，我们想和你在这个节目中进行对话的原因就是希望你能分享这些细节。我认为现在从你这里听到这些，与通过博客文章（黑白文字）相比......你无法看到面孔或听到语调，也无法理解某人的真诚，因此很难了解一个组织做出这样的选择的真正原因，而现在从你这里听到的这些是有道理的。你确实是试图在公开的环境中做这件事，试图拥抱社区，这对我来说非常酷。我很感谢你有这样的感觉，因为这表明你关心并拥抱黑客社区，而你当然是其中的一部分。你不再只是Docker，你依然是那个老旧的Solomon，但我认为你采取的这种方式很酷。只可惜最终却适得其反。
Solomon Hykes: 是的。谢谢，我很感激。说实话，过去四年我们处理的事情中，这次的反响算是相对温和的。目前我们只专注于改进它，并关注Moby带来的酷炫功能。
关于Moby，除了名称分离之外，最酷的是现在有了开放源代码项目和开放源代码产品的地方......真正令人兴奋的是，它使我们能够进一步将平台拆分成组件，而这正是其重要之处，因为Moby并不是一个代码库，而是一个组件的集合。它几乎像一个发行版。它并不是Docker的所有组件的家，Docker有很多组件---比如Containerd、SwarmKit、Libnetwork、Notary......还有很多其他的，每一个都作为独立项目推出。
如果你喜欢Containerd---Containerd是核心容器运行时，做所有这些事情，但没有承载Docker平台的额外负担和看法；它只是运行Linux容器，提供低级API来实现这一点，正在成为执行这一操作的事实标准。因此，即使你不使用整个Docker，如果你在使用容器，很可能会使用Containerd。我们把这个项目捐赠给了一个独立的基金会---我们把它捐赠给了CNCF......所以它不是Moby的一部分，但Moby将其集成到我们称之为"组件组合"的内容中。
我们将对每一个组件做同样的事情，最终你会看到三个阶段，我在你之前粘贴的聊天中画的那个小铅笔画；我们在供应链中有三个阶段。最上游是各个组件，然后将它们集成到Moby中，但关键是因为它在社区项目中集成，Moby中的不同参与者可以以不同的方式集成这些组件。
可以把它想象成一个乐高俱乐部。你去乐高俱乐部，有一个巨大的箱子，里面装满了你梦寐以求的所有零件，然后大家都聚在这个大桌子上，每个人都在做自己的城堡、雷神或其他东西，如果你想加入一群孩子一起玩，你可以加入，但重点是你可以做自己的......而且，没有强制性的乐高建设你必须参与。这就是我希望在接下来的几个月中强调的Moby方面，而不是名称更改。它在这方面真的很酷，或者一旦我们完善工具，它会变得更酷。你的容器平台会有无数种变化，而Docker只是其中之一。
在这种情况下，Docker就像一个专业的乐高艺术家，有很多人喜欢我们的乐高创作，但我们会和其他人一起待在同一个俱乐部，在同一张桌子上构建我们的乐高作品，与其他人合作，如果有人喜欢，他们可以像以前一样加入，因为这是开源的......但如果他们不喜欢，或者他们只喜欢其中的一部分，想用同样的乐高砖做不同的事情，他们也可以做到。在这个比喻中，Moby就是俱乐部---就是桌子，就是装满所有砖块的箱子。这才是Moby的真正目标。
Adam Stacoviak: 或许我们可以请你再次回到Changelog来深入讨论这个部分。很遗憾我们花了很多时间讨论名称变更，因为我觉得这必须谈论，但在没有讨论名称变更的情况下，无法谈论你提到的接下来六个月的事情，这确实让很多人困惑。
你花了好几年时间为Docker和这个开放容器规范辩护，试图做不同的事情，这种转变似乎是对多年来你提到的各种批评的回应。
Solomon Hykes: 是的。或者我们叫它建设性的反馈。[笑声]
Adam Stacoviak: 没错，建设性的反馈。批评是我的词......我不认为你直接这么说，所以我不是在给你下定义。
Solomon Hykes: 需要记住的是，当我们开始Docker时，我们在DotCloud开源过东西，但从未达到过那个规模，对吧？而且，这还是公司开源；没有真正努力去创造一个人人平等参与的社区。但从第一天起，Docker就是这样的模式；我们把它隔离了。我们在这个过程中学到了很多东西。我们观察其他项目的做法，进行了模仿......我们还尝试了很多人告诉我们是好主意的规模化做法，然后因为在我们这个规模下，这些做法并不好而破坏了。人们常常忘记，能够在Docker规模下运作的项目非常少。
确实有项目，我们不是唯一的，也不是最大的，我们绝对在前0.1%之内。就像系统在大规模下的行为会有所不同，有时候规则也会改变---在小规模下看似显而易见的事情，在大规模下可能会神秘地破裂；对于项目来说也是一样的道理。
所以部分原因是我们必须向那些做开源的人解释，他们为自己做开源而感到自豪，并且自信地认为他们了解开源---他们确实了解，但他们不了解我们这个规模的开源。现在我听自己说，这听起来有点自大，但我们也必须面对这个现实。有时候，现实是我们更了解，但这不是一个受欢迎的说法。
我们只是去尝试，然后努力回应。如果有人指出某些东西坏了，我们总是倾听，并积极工作去修复它。在内部，我们团队有一种文化，总是讨论破损的东西，总是谈论问题，我觉得我们也许应该做得更好，去展示这一点......但我们真的在做。
不过，我们面临的问题是，因为我们是如此大的目标，每天我们都收到数百条反馈；我们受到一百多条批评，我们必须从那巨量的批评中提取出最重要和可行的内容。为了做到这一点，我们需要从那些情绪不佳的人、那些只有特定小众用例的人、那些在谈论意见而非事实的人中筛选出来......这需要时间，确实很困难，我们总是害怕，"我们是否遗漏了被噪音淹没的重要反馈？"顺便说一下，如果你知道哪些工具或技术可以帮助做到这一点，我们一直在寻找。
Erik St. Martin: 我知道我们还有几分钟的时间......我很好奇，现在我们有了Moby和分离，你提到过接下来的六个月......你对Docker未来一年的愿景是什么？五年的愿景又是什么？如果你有无限的时间来自己对Docker进行开发，你会驱动什么？你希望看到什么样的功能？
Solomon Hykes: 很好的问题。[笑声]
Adam Stacoviak: 你把他打败了。
Solomon Hykes: 抱歉，我刚刚在想我整天黑客编程的事情......[笑]
Adam Stacoviak: 不错，Solomon。
Solomon Hykes: 你知道，现在有两组用户对Docker非常兴奋，迫切希望得到更多的东西：开发者和运维人员。我认为运维人员面临着一个巨大的问题，他们需要---他们需要一种新的操作系统，因为现在不再是单独的服务器了，而是像我们所知道的那样，大量的集群，多个集群，机器随时可能消失或在其他地方重新出现，基础设施变得极其复杂、快速变化且规模庞大，而现有的工具和操作系统显然跟不上。
所以，大型科技公司构建了自己的定制分布式操作系统，但其他所有人只能拼凑工具和组件，然后用大量的胶带把它们结合在一起，试图创建一个运行它们的操作系统......而我们想要构建的就是这个。
我们从DotCloud的经验中学到一件事：你不能以单体的方式构建这个系统；你必须以模块化的方式来构建。因此，我们要么构建缺失的部分，要么与其他正在构建缺失部分的团队合作，然后学习如何将这些组件整合到一个合理、可在大规模下可靠运行的系统中。老实说，我们还有很多工作要做。这是我想要专注的事情，也是我们正在积极开发的方向。
另一个方面是开发。外面有很多人有很酷的想法，他们想用代码构建一些东西，但这仍然太难了。老实说，我觉得我们已经退步了，甚至比Basic或Excel公式的时代还要糟糕。那些都是让更多人能够使用编程来解决问题的巨大进步。
Erik St. Martin: 或SQL。
Solomon Hykes: SQL确实很酷，但你仍然需要连接到其他东西，对吧？但我想你说得对，它确实能表达与数据的交互。实际上，SQL也在这个列表之中。
Erik St. Martin: 是的，在那之前，你必须自己编写存储层以及如何检索和处理这些东西，这真的让它在更高的层次上变得更容易接触。
Solomon Hykes: 对我们来说，因为Docker现在真的成了很多开发者的灯塔，他们想要构建一些东西，但面临很多问题，他们需要工具来解决这些问题，于是他们来找我们，告诉我们："嘿，我想做这个......你能帮我吗？"老实说，今天即使我们开发了很多工具，90%的时候我们的回答都是："不，我们真的帮不了你。没有这样的工具。"但这让我们更想去构建这些工具。
所以我只想让开发者的工作变得更简单。老实说，我认为我们才刚刚开始......而我不仅仅是指Docker。我是说，作为一个为他人制作工具的社区，我们还有很多工作要做。我认为我们需要提高标准；我们做得还不够好。
Erik St. Martin: 我想我们差不多到尾声了；可能会超出几分钟......但还有几个问题，我们看看有多少时间。有人问，我记得是Marwin，在GoTime频道里提到，他读到了从REST API转向gRPC的变化，以及这背后的原因和细节。
Solomon Hykes: 哦，是的。这是Moby的一部分令人兴奋的内容---我们现在有了Moby项目，一个很好的框架，可以将Docker平台拆分成不同的组件，每个组件更具专业性，比如Containerd，Containerd就是一个很好的例子。每个组件几乎就像一个小的微服务，对吧？从某种意义上说，我们在说："如果每个应用程序都朝着微服务模型发展，那为什么运行这些应用程序的平台本身也不采用微服务模型呢？"这似乎是正确的做法。
曾几何时，我们试图为此编写自己的RPC层......我们早期在DotCloud有一个项目叫ZeroRPC，然后我们进行了很多与HTTP/2和SPDY扩展的实验。在HTTP/2出现之前，所以我一直是寻找合适的RPC层的忠实粉丝，但我们从来没有时间真正推动那个项目。后来gRPC出现了，并得到了广泛的关注，我看到Docker的很多工程师都在使用它。
Containerd是一个gRPC接口......它正在逐渐流行，因此选择一个RPC层作为低级接口是一个务实的选择。你可以生成所有客户端和SDK等，这真的很不错。
现有的Docker API是一个更高层的API，目前是HTTP REST API。现在我们正在制定这个API的路线图。绝对的优先事项是确保不打破现有用户。因此，HTTP REST API将继续存在，因为我们当前的用户和生态系统在使用它，我们不想打破他们。
所以这更多的是针对所有新API的前进方向。我们首先使用gRPC，因为这是我们特定社区中人们使用的默认选项，但就是这样。如果你有兴趣讨论这些，顺便说一下，你应该加入Moby论坛---forums.mobyproject.org。
Adam Stacoviak: 这是另一个很好的问题，任何结束的想法？我们快到尾声了，但这是一个很好的推广......如果你有讨论想要进行，那是个很好的地方，但在我们结束节目之前，Solomon，你还有什么想分享的吗？有什么结束的想法，或者是给Go社区采用Docker/Moby的一些建议？
Erik St. Martin: ...为Docker做贡献？
Adam Stacoviak: 是的。
Solomon Hykes: 我认为Moby的整体目的就是将这个项目或一系列项目提升到一个新的水平。如果你对参与有兴趣，或者还在犹豫是否贡献，我认为现在实际上是一个很好的时机，因为Moby表明我们在开源方面投入了更多精力；我们希望更多人参与进来，并且愿意提供帮助。
尤其是如果你是开源的新手，我们发现即使是有经验的程序员也可能对第一次贡献感到犹豫；这是一种巨大的信任飞跃，感觉很陌生......有时你可能会觉得这里像是一个俱乐部，而你可能不受欢迎，也许有些私人笑话你无法理解。随着我们社区的发展，这一点是我们必须时刻牢记的。
在Docker初期，我们付出了很多努力，使其成为一个非常棒的地方，适合进行第一次开源贡献。我希望Moby也能做到这一点。所以如果你有兴趣，请来参与，我们可以一起讨论。
Erik St. Martin: 我还想补充一点关于贡献的事情---如果你的拉取请求等待了很长时间，不要感到沮丧。Docker上有很多拉取请求，可能需要一个月才能处理完。我自己也有过请求等待的经历。项目实在太活跃了。
Solomon Hykes: 是的，如果你查看Docker的文档，会有一个专门的部分讲述如何贡献，我们将继续维护这个部分。我们还组织活动，特别的Docker聚会，你可以参加，在那里有导师帮助你选择适合的贡献项目，然后帮助你完成这个贡献。
所以这些活动对于开始开源贡献来说是一个很好的方式。
Adam Stacoviak: 我真的很遗憾我们没有讨论为什么叫Moby，以及这个名字的由来，但我们可以留到下次再谈......我只是想提一下，因为命名真的是一件很难的事情，对吧？
Solomon Hykes: 是的，这是吉祥物的名字。大约两年前，我们进行了投票，征求社区对吉祥物、鲸鱼的名字的选择，社区选择了MobyDoc。现在，两年后，我们在创建一个项目，我们希望与Docker的联系明确，但也希望它有自己的身份，与Docker分开。我们借鉴了红帽对Fedora的做法---它是一个帽子，有点像参考，我们也做了同样的事情。如果你看标志的话，它是鲸鱼的尾巴。就是这样。
Adam Stacoviak: 说得很好......不错。
Erik St. Martin: 我们已经超时了，但很高兴你能参加这个节目，Solomon。我真的很高兴你有机会来和我们谈谈Docker。
Solomon Hykes: 我很高兴。谢谢你们邀请我，我喜欢谈论这些话题。
Erik St. Martin: 希望我们能继续请你来，随着Docker的不断发展和在运维、开发领域的扩展。
Solomon Hykes: 我很乐意。随时都可以！
Erik St. Martin: 感谢其他参与节目的朋友---Carlisia和Adam，谢谢你们从幕后走出来和我们聊天。
Adam Stacoviak: 随时欢迎！
Erik St. Martin: 感谢我们的赞助商Toptal对节目的赞助。一定要把节目分享给其他Go程序员。你可以在GoTime.fm找到我们，那里可以订阅我们的周刊......我们在Twitter，如果你想参加节目，或者有问题想问我们的嘉宾，请联系我们......那么，再见，大家！下周见。
Adam Stacoviak: 再见！
Carlisia Thompson: 这真是太好了！谢谢你，Solomon。
Solomon Hykes: 谢谢你。