Docker 犯下的三个致命错误：一号员工十周年的反思

原文链接：https://thenewstack.io/docker-at-10-3-things-we-got-right-3-things-we-got-wrong/

作者：Sam Alba，Dagger 联合创始人兼工程副总裁，曾任 Docker 的工程副总裁。2010 年作为一号员工加入 Docker，带领工程团队并将其规模从 3 人扩大到 100 人。

Docker 最近庆祝了 10 岁生日。我为我们在 Docker 取得的成就感到非常自豪，团队也持续取得的惊人成就。如果「容器」没能成为新的计算单位，现在许多我们周围的东西都不会存在了：微服务架构，Kubernetes 等等。当你回顾你生活中重大转折点时，相信你会看到你做对了和没做对的事情，至少对我来说是的。

话不多说，让我们来看下 Docker 十年的对与错。

三件做对的事

容器改变世界

我 2010 年加入 Solomon Hykes 一起建立 DotCloud（后来更名为 Docker）时，我很快就清楚地意识到，如果只使用当时已有的工具，将永远无法实现我们的愿景。DotCloud 是第一个支持所有语言的平台即服务（PaaS），而 Heroku 和其他平台仍然局限于单一语言堆栈。在构建 DotCloud 时，我们面临的一个挑战是缺乏虚拟机（VM）替代品，作为关键基础设施的构建模块。虚拟机相对于裸机是一个巨大的进步，但它们未能提供迈进云原生时代所需的灵活性。我们需要某种足够轻量的东西，在单个机器上打包数百个开发者的应用之际可以将每个用户隔离在自己的独立命名空间中（计算、网络、存储）。

这标志着微服务模式的开始。虚拟机仍然是基础设施可重复性方面最先进技术，并且容器仍然是少数爱好者专用技术（记得 LXC 要求内核补丁才能连接到正在运行的容器吗？）。也有人认为解决方案是让虚拟机进行零碳饮食（记得 JeOS 吗？）。对我们来说很明显，尽管面临诸多挑战，但围绕容器构建一切的努力是值得的。最终，我们证明了自己是正确的。

几年后，我们从 DotCloud 平台中提取出一个核心组件：容器运行时（Container Runtime）。我们对其进行了重写并开源，这就是 Docker 的第一个版本。最初的目标是让 Docker 成为从 DotCloud 中提取出来的众多开放组件之一。容器编排器和网络层将很快随之而来。但由于 Docker 在早期就受到了极大关注，计划发生了很大变化。

开发者，开发者，开发者

Steve Ballmer 是对的。在 VMware 主要关注解决 IT 问题时，我们已经意识到改变世界的方法是从全球的开发者开始。你必须改变软件构建的方式，而不仅仅是如何使用，这意味着首先满足开发者的需求。作为管理数千名开发者的人，我深知软件开发人员每天面临的挑战。这可能是世界上最棒的工作之一，充满了具有挑战性的问题和创造美好事物所带来的满足感，但也可能无聊，沮丧，有时还会令人愤怒。

基础设施和工具都有了巨大进步，但标准也提高了。Docker 当时的北极星指标是减少干扰、降低成本，并使开发者能够高效合作。其中一个我们最早收购（并）的产品叫做 Fig，最初由 Ben Firshman（Replicate 创始人）和 Anand Prasad 打造，后来整合进 Docker 成为了 Docker Compose。有趣的是，Fig 实现的 YAML 模型（compose.yml）直接受到了我们多年前构建 DotCloud 服务组合（dotcloud.yml）的启发。虽然我们取得了很大进展，但还有更多工作要做，特别是超越容器作为唯一单元，并编排容器流水线。这就是为什么我们在 2018 年开始打造 Dagger 的原因之一，它是一个可编程的 CI/CD 引擎，在容器中运行你的工作流。

投资建设活力的社区

我们最初专注于建立一个优秀的社区。从第一天开始，我们就深信我们无法独自实现所追求的目标。这需要赢得许多人的心和思想，并且实现这一点的关键是放弃对很多事物的所有权。DockerCon 成为了这个行业中最优秀聪明的人们聚集在一起的地方，他们分享事物如何发展，并愿意付出努力来构建共同愿景。在 Docker 早期，我们考虑自己组织开发者大会时，听起来甚至有点离谱。这要么是大公司才会准备，要么是针对更成熟的开发者社区（例如 PyCon）。

但 2014 年 6 月我们在旧金山组织了第一届 DockerCon，并将一些才华横溢的开发者聚集在同一个地方时，显然它只是某个变革之始而已，将改变 Docker 和整个行业。这种精神至今仍然深入人心，在数十个（甚至是数百个）开源项目和社区中都可看到。云原生计算基金会（CNCF）如今是其中许多活动的主办方，而且每天还在不断涌现更多新的活动。

三件做错的事

用户 vs. 客户

把社区放第一的背面是，我们花了太长时间才建立起一个可持续发展的业务。我们的偏见是要在公开透明的环境中尽力倾听社区需求，并努力满足他们。这个策略的根基是开源项目和商业专有解决方案可以很好地共存，并成为同一客户旅程的一部分。我今天仍然相信这种模式，但它需要一个微妙的平衡。

首先，你必须接受一些开源贡献者和用户永远不会成为客户。这没关系，因为他们参与构建了强大的社区、强大品牌，进而促进商业渠道增长。其次，产品架构必须允许在核心开源基础上构建企业级功能。这通常伴随着复杂的支持和发布流程。我们当然可以在创造稳固业务路径时更加战略性一些。最终我们实现了目标，但花费了太长时间，并且经常感到害怕。

明确文化

我们没有在早期明确定义团队文化和核心价值观，它们后来被社区和后来加入公司的人所定义。这导致我们的团队文化发生了很大变化，虽然一开始并不明显。Docker 的文化最终反映了社区的风格和价值观，而不是反之。

一个具体的例子是，在我们公司内有两个独立群体：一个专注于开源和社区，另一个专注于商业，这是我最大的遗憾之一。它演变成为内部工具、产品和项目管理以及团队文化本身上出现不同的思维方式。对任何人来说，平衡这些竞争利益都很难，但当你把角色分开时，就会产生内部斗争、不一致性和难以有定论的辩论（每个人都从自己的角度认为自己是正确的）。很多优秀的人在社区工作，但在和商业侧的许多合作中，还是经常会有微妙（或直接）的评判。有时候感觉是「开源信仰者」与「企业赚钱者」的对抗。这只会导致低效。

同时拥有一个充满活力的社区和可持续发展的商业模式所需要的，是一支无时都因这个模式而挣扎，但又能融合在一起的团队。它还能创造更好的团队文化。无论在公司的哪个部门工作，只有一个目标值得关注。

容器作为宇宙中心

退后一步看时，我意识到我们过于依赖容器：我们将容器视为大多数问题的核心解决方案，这使我们对开发供应链的其他需求变得盲目。Docker 之所以诞生，是因为我们看到容器将在行业内引发一系列必要的变革，但随着发展，我们没有关注后续需求，这就为他人留下了许多进入并开拓疆土的空间。一方面，这留下了很棒的机会，但也意味着社区的分裂。一个例子是在 Docker 中未能解决的挑战之一就是软件供应链完全自动化。虽然在那个供应链末端释放了很多价值，但却没有充分满足开发人员编码和合作的需求，直至今天 CI/CD 仍然混乱不堪。但它是可以解决的混乱局面。

像 Solomon Hykes，Andrea Luzzardi 和我许多同代人一样，在回顾 Docker 的期间时，意识到我们所推动的革命还不完整，因此找到了未来十年的目标。

---

更多资讯，请关注 Bytebase 公号：Bytebase