Docker十年的得与失

本文首发：分布式实验室

本文作者 Sam Alba 目前是 Dagger 联合创始人兼工程副总裁，他也是 Docker 的前工程副总裁。他于 2010 年作为第一位员工加入 Docker。他带领团队从 3 人扩大到 100 人。他领导过核心产品和工程团队，负责支持各个关键的 Docker 产品。

本文写于 Docker 十周岁之际，回顾了这十年来 Docker 的成功与失败。

Docker 最近刚刚庆祝了它的十周岁生日。对于我们在 Docker 所取得的所有成就，我感到无比骄傲，同时团队现在依然有着令人瞩目的成绩。

如果不是容器成为新的计算单元，我们现在所见的很多事物 —— 基于微服务的架构、Kubernetes 以及其他很多内容 —— 都不会存在。我认为，当你回首自己人生中的重大转变时，你既会看到你做对的事情，也会看到你犯的错误，这是毋庸置疑的。

不再啰嗦了，让我们来探讨一下 Docker 这十年的对与错。

#01

我们做对的三件事

让容器改变了世界

当我在 2010 年与 Solomon Hykes 共同创立 DotCloud（后来重命名为 Docker）时，我们很快意识到，如果仅仅依赖当时已有的工具，我们的愿景将无法实现。当时，DotCloud 是首个支持所有语言的 PaaS 平台，Heroku 和其它平台仍只支持单一的语言栈。

在开发 DotCloud 时，我们面临的一个主要问题是，作为主要的基础设施构建模块，我们缺乏 VM（虚拟机）的替代品。虽然与裸机相比虚拟机对于基础设施世界来说是一个巨大的进步，但它们还不能提供我们进入云原生时代所需的敏捷性。

我们需要一种足够轻量的技术，可以让我们为每个客户隔离出自己的命名空间（计算、网络、存储），同时在一台机器上运行数百个开发者的应用。这标志着微服务模式的诞生。

那时，VM 仍然是基础设施可重复性的最先进技术，而容器技术还是一个鲜为人知的领域（你还记得当时 LXC 需要一个内核补丁来连接正在运行的容器吗？）。有些人认为解决方案是进一步 “精简” 虚拟机（还记得 JeOS 吗？）。但我们坚信，尽管面临种种挑战，采用容器来构建一切仍是值得的。后来事实证明，我们是对的。

几年后，我们从 DotCloud 平台中提取出了一个核心组件，即容器运行时，并对其进行了重写，然后将其开源。这就是 Docker 的最初版本。我们的初衷是将 Docker 作为从 DotCloud 中提取出的许多开放组件的第一个。而容器编排器和网络层则计划在其后发布。但由于 Docker 在早期受到了太多的关注，我们的计划发生了很大的改变。

重视开发者

Steve Ballmer 的观点是正确的。虽然 VMware 主要集中于为 IT 部门解决问题，但我们很早就认识到，要真正改变世界，关键还得聚焦全球软件开发者。这意味着我们不仅要改变软件的运行方式，更要从根本上改变其构建方式，并且这一切都要以开发者的需求为出发点。

作为一个曾经管理过上千名开发者的人，我深知软件开发者每天面临的挑战。软件开发既可以是世界上最令人兴奋的工作，充满了各种挑战和满足感，但有时也可能令人疲惫、沮丧，甚至是愤怒。虽然基础设施和工具已经取得了巨大的进步，但我们所面对的挑战也日益增长。

在 Docker，我们的核心目标是尽量减少干扰，降低运营成本，从而让开发者能够更高效地工作和协同合作。

我们首次收购并成功整合的是一个名为 “Fig” 的产品，它后来成为了 Docker Compose。该产品最初是由现 Replicate 创始人 Ben Firshman 和 Anand Prasad 构建的。有趣的是，Fig 使用的 YAML 模型（compose.yml）正是受到我们多年前构建的 DotCloud 服务组合模型（dotcloud.yml）的启发。尽管我们在这方面取得了很大进步，但还有许多工作尚待完成，特别是需要超越单一容器单位，向容器流程编排方向发展。这也是我们在 2018 年启动 Dagger 的原因，它是一个能在容器中运行你的工作流的可编程 CI/CD 引擎。

建设了充满活力的社区

我们从一开始便致力于构建一个强大的社区。从一开始我们就坚信，要实现我们的目标，不能只依赖自己。要取得成功，关键是要赢得大众的支持和信任，并放弃对有些事情的控制。DockerCon 逐渐成为了这个行业中最杰出和最聪明人的聚会。他们都有一个共同的愿景，并且愿意为之努力工作。

在 Docker 的早期，我们曾考虑过自己组织一个开发者大会，但这似乎是一个遥不可及的梦想，仿佛这样的事情只有大公司或更为成熟的开发者社区才会去做，例如 PyCon。

但当我们于 2014 年 6 月在旧金山举办第一届 DockerCon，并聚集了一群才华横溢的开发者时，我们才明白这将改变整个公司乃至整个行业。如今，这种遗产在我们所看到的众多开源项目和社区中仍然生机勃勃。CNCF 现在就是许多这些项目的托管者，而且每天还有很多项目涌现出来。

#02

我们错了三件事

普及与盈利的矛盾

“社区至上” 的另一面是我们需要花费很长的时间来建立一个可持续的业务。我们的初衷是公开所有事情，认真听取社区需求，尽我们所能满足他们。这一策略致力于让开源项目和商业的、专有的解决方案可以和谐共存，服务同一客户。

至今我仍信任这种模式，但需要平衡。首先，你必须认识到一些开源贡献者和用户永远不会转变为付费客户。但这并不是问题，因为他们在构建强大的社区和品牌上起到了作用，这有助于扩大商业渠道。其次，产品设计必须基于开源的核心来构建适合企业的特性。这经常伴随着复杂的支持和版本发布过程。

在建立商业模式的过程中，我们本可以更具策略性。尽管我们最后实现了目标，但走的路线过长且充满了不确定性。

没有明确团队文化

我们开始并没有早早地明确团队的文化和核心价值观，导致后来这些文化和价值观被社区或后来加入的员工所塑造。这种渐变使得我们初创时期的团队文化和后期有了很大的不同，这在开始时并不明显。最终，我们的文化更多地反映了社区的风格和价值，而不是我们早期的原始设想。

一个具体的问题是我们公司有两个独立的团队，一个团队专注于开源和社区，另一个团队专注于商业方面。我非常后悔这样的决策。这种划分导致了工具、产品和项目管理，以及团队文化本身的双重标准。当你这样分隔角色，内部就会出现冲突、前后不一致，还有很多无法解决的争论（每个人都觉得自己是对的）。

很多有能力的人都想在社区团队工作，而与商业团队的合作中往往会有明显的偏见。有时，感觉就像我们有一群 “开源信仰者” 对抗 “商业现实主义者”。这样并不好。既要建立一个活跃的社区又要有稳定的业务，需要的是一个融合的团队，大家都面对和理解同样的挑战和压力。这样也能形成更加团结的团队文化。不论你在公司做什么，所有人都应该只有一个目标。

视容器为万物中心

后来我深思熟虑，发现我们过度依赖容器了。我们开始将容器视为解决大多数问题的核心方案，导致我们忽视了开发供应链中的其他需求。

Docker 之初，我们看到容器将带来行业内一系列必要的变革，但随着时间的推进，我们并没有关注接下来的需求。这种疏忽为其他公司提供了进入和发展这些领域的空间。这种情况既是一个巨大的机会，也会让社区分散。

我们在 Docker 面临的一个挑战就是软件供应链的完整自动化。我们确实在供应链的尾端创造了巨大价值，但并未足够关注开发者在编程和合作时的需求，导致今天的 CI/CD 仍然混乱。但是，这是一个有解决方案的问题。和那个时代的许多人一样，当我与 Solomon Hykes 和 Andrea Luzzardi 回顾我们在 Docker 的日子时，我们认识到我们的变革还未完成，这促使我们为接下来的十年找到了新的目标。