服务器之家:专注于服务器技术及软件下载分享
分类导航

服务器资讯|IT/互联网|云计算|区块链|软件资讯|操作系统|手机数码|百科知识|免费资源|头条新闻|

服务器之家 - 新闻资讯 - 云计算 - 那些对与错,Docker十年的得与失

那些对与错,Docker十年的得与失

2023-10-19 12:00未知服务器之家 云计算

本文作者 Sam Alba 目前是 Dagger 联合创始人兼工程副总裁,他也是 Docker 的前工程副总裁。他于 2010 年作为第一位员工加入 Docker。他带领团队从 3 人扩大到 100 人。他领导过核心产品和工程团队,负责支持各个关键的 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 的日子时,我们认识到我们的变革还未完成,这促使我们为接下来的十年找到了新的目标。

延伸 · 阅读

精彩推荐