不要把容器当做宇宙的中心！Docker成立十周年：来自1号员工的反思

作者丨Sam Alba

编译丨诺亚

本文作者Sam Alba目前是Dagger的联合创始人兼工程副总裁，也是Docker的前工程副总裁。他于 2010 年作为第一位员工加入 Docker。他领导了工程团队，将其从三名成员扩展到 100 名成员。随后，他领导核心产品和工程团队，负责支持各种关键的Docker产品。

Docker最近庆祝了其成立10周年。我为Docker 从过去到现在取得的所有成就感到非常自豪。如果容器没有成为计算消费的新单元，我们周围看到的很多东西——基于微服务的架构、Kube.NETes 等等——都不会存在。

另外，我敢肯定，当你回顾生命中的转折点时，你会更清晰地看到一路走来的得失。这对我来说是千真万确。事不宜迟，让我们一起看看当初我们做对了什么，又在哪些地方犯了错。

当我在2010年加入Solomon Hykes构建DotCloud（后来更名为Docker）时，我很快就意识到，如果我们只使用当时存在的工具，我们将永远无法实现我们的愿景。

DotCloud是第一个支持任何语言的平台即服务（PaaS），而Heroku和其他公司仍然仅限于运行单一语言堆栈。我们在构建 dotCloud 时立即面临的一个限制是缺乏虚拟机（VM）作为关键基础架构构建块的替代方案。虽然虚拟机相对于基础设施领域的裸机服务器向前迈出了一大步，但它们未能提供我们进入云原生时代所需的敏捷性。

我们需要足够轻量级的东西，以便我们可以将每个客户隔离在他们自己的命名空间（计算、网络、存储）上，同时在一台计算机上打包数百个开发人员应用程序。这是微服务模式的开始。彼时，在基础设施可重复性方面，VM仍然是最先进的技术，而容器仍然是一种鲜为人知的技术，只有少数修修补补者才能使用(还记得LXC需要一个内核补丁来连接到运行中的容器上吗?)其他人认为解决方案是让VM进行零碳水饮食(还记得JeOS吗?)。

我们很清楚，尽管面临各种挑战，但围绕容器构建一切都是值得的。最终，事实证明我们是对的。几年后，我们提取了DotCloud平台的核心组件:容器运行时。我们重写了它并开放了它的源代码。这是Docker的第一个版本。最初的目标是让Docker成为从DotCloud中提取的众多开放组件中的第一个。容器编排器，即网络层，将紧随其后。但是考虑到Docker在早期获得的即时关注，时间表发生了很大的变化。

史蒂夫·鲍尔默是对的。VMware 主要专注于为 IT 解决问题，而我们很早就意识到，改变世界的方式是专注于全球的软件开发人员。你必须改变软件的构建方式，而不仅仅是操作方式，这意味着首先从开发人员的需求开始。

作为一个管理过数千名开发人员的人，我非常清楚软件开发人员每天面临的挑战。这可能是世界上最令人难以置信的工作之一，充满了具有挑战性的问题和创造美好事物的满足感，但它也可能是乏味的、令人沮丧的，有时甚至是令人愤怒的。基础设施和工具取得了巨大进步，但标准也提高了。

我们在Docker的目标是减少干扰、成本，让开发人员高效协作。最早的收购（和成功的产品集成）之一是一个名为“Fig”的产品，后来成为Docker Compose，最初由Ben Firshman（现Replicate创始人）和Anand Prasad构建。

有趣的是，由Fig (composition .yml)实现的YAML模型直接受到了我们几年前构建的第一个DotCloud服务组合(DotCloud .yml)的启发。虽然我们取得了很大的进展，但还有更多的工作要做，特别是超越容器作为唯一单元和编排容器管道的范围。这就是我们在2018年启动Dagger的原因之一，这是一个可编程的CI/CD引擎，可以在容器中运行你的管道。

我们首先专注于建立一个伟大的社区。从第一天起，我们就相信我们无法独自实现我们想要实现的目标。它需要赢得一大群人的心，而实现这一目标的关键是放弃对很多事情的所有权。DockerCon 成为我们行业中许多最优秀和最聪明的人的聚集地，人们聚集在一起，他们对事物如何发展有着共同的愿景，并愿意卷起袖子投入建设它。

在Docker的早期，当我们考虑自己举办开发者大会时，最初听起来像是一个遥不可及的梦想。要么适用于大公司，要么适用于更成熟的开发人员社区，例如 PyCon。但是，当我们于 2014 年 6 月在旧金山组织了第一届 DockerCon 并能够在同一地点聚集一些才华横溢的开发人员时，很明显，这是将颠覆整个公司和行业的划时代的开端。

今天，在我们行业中看到的数十个（或者数百个？）开源项目和社区中，这种遗产仍然很强大。今天，云原生计算基金会(Cloud Native Computing Foundation)成为了其中许多项目的东道主，而且每天还会有更多的项目涌现出来。

“社区优先”的另一面是，我们花了太长时间来建立一个可持续的业务。我们倾向于公开做所有事情，认真倾听社区的需求，并尽我们所能为他们提供服务。该策略的最初基础是开源项目和商业专有解决方案可以很好地共存，并成为同一客户旅程的一部分。

我今天仍然相信这个模式，但这是一种棘手的平衡。

首先，你必须接受一些开源贡献者和用户永远不会成为客户的事实。考虑到他们参与建立一个强大的社区，一个强大的品牌，这对商业渠道的增长有贡献，因而也没关系。其次，产品架构必须允许在核心开源基础上构建企业级功能。这通常伴随着复杂的支持和发布过程。我们本可以在创建稳固业务的道路上更具战略性。最终，我们到达了那里，但花了太长时间，也因此经常感到害怕。

我们没有在早期定义团队文化和核心价值观。它是后来由社区或后来加入公司的人定义的。这导致我们的团队文化从早期开始就发生了巨大的变化，一开始并不明显。我们的文化最终反映了社区中人们的风格和价值观，而不是相反。

我们犯错的一个具体例子是，我们公司有两个独立的团队——一个专注于开源和社区，另一个专注于业务。这是我最大的遗憾之一。

它在内部工具，产品和项目管理以及最重要的团队文化本身方面变成了一个分裂的大脑。每个人都很难平衡这些相互竞争的利益，但当你把角色分开时，你最终会陷入内部斗争、不一致和永远无法解决的公开辩论(从他们的角度来看，每个人都是对的)。

许多最优秀和最聪明的人都想在社区方面工作，而在我们的许多合作中，往往会对另一方产生微妙(或不那么微妙)的判断。有时感觉我们让“开源信仰者”与“企业赚钱者”对立起来。这样做毫无成效。要同时拥有一个充满活力的社区和一个可持续发展的业务，就需要一个整合的团队，让每个人都与我们的模式自然产生的固有紧张关系作斗争。这也创造了更好的团队文化。不管你在公司的哪个部门工作，你只需要关心一套目标。

当我退后一步时，我意识到我们过于依赖容器了。我们开始将容器视为大多数问题的核心解决方案。这让我们忽视了开发供应链的其他需求。

Docker的诞生，是因为我们看到容器将为我们的行业带来一系列必要的变化，但随着事情的发展，我们并没有关注后续的需求。由于我们留下了这么多未解决的需求，我们为其他人创造了大量的空间，让他们可以介入并建设这些领域。

一方面，这留下了巨大的机会，另一方面也意味着社区的分裂。我们在Docker没有解决的挑战之一是软件供应链的整体自动化。我们在供应链的末端释放了如此多的价值，但却没有充分解决开发人员编码和协作时的需求，今天的CI/CD仍然是一团糟。但这是一个可以解决的烂摊子。像那个时代的许多其他人一样，当Solomon Hykes，Andrea Luzzardi和我回顾我们在Docker的时光时，我们意识到我们的革命仍未完成，因此我们找到了下一个十年的使命。

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