周六上午参加了一场有关中国开源软件的线上 Panel，这次不同于以往的潜水，拿到了嘉宾身份牌，还真的是头一回。接着下午又看了 Kubernetes: The Documentary，正好就着图，交织着各种回忆，把感想一起写一下。

笔者是 2013 年加入的 Google，到 2018 年离开，时间线基本和 Kubernetes 项目重合。自己一直在 Google Cloud SQL 这个项目上，Cloud SQL 一开始的版本是构建在内部的 Borg 上，等第二版重构到 GCE 上时，记录片中的人物都已经从 GCE 转到了 Kubernetes 项目上，所以我恰好和他们完美错过，只有零星的记忆碎片，和其中某些人有过简单的交谈。

想想事情也很奇妙，如果当初我和他们其中的某个人有更多工作上的来往，自己也很有可能想加入 Kubernetes 团队，因为系统设计和领域建模同样是我的兴趣所在，不过兜兜转转，最终我还是留在了数据库领域。

生态 (Ecosystem) 和共识 (Consensus)

Panel 里大家提了很多次生态（Ecosystem)，也有同学问什么是生态。我理解的生态代表的是社区 (Community) 的共识（Consensus)。共识是有稀缺性的，毕竟最多只有一方可以超过 50%。因为有稀缺性，所以会形成争夺。共识有两个层面，一个是理念的共识，一个是实践的共识。

Google 早年只强调理念，发了 BigTable, MapReduce, GFS 三篇论文，而把实践交给了社区。结果最受益的是 AWS，基于 MapReduce/GFS 的 EMR 和基于 BigTable 的 DynamoDB 都是 AWS 的现金奶牛。

后来 Google 能下把 Kubernetes 开源出来的决心，多少也是因为吃亏得来的教训。

理论虽然有高度，但还是实践出真知。有句话叫

起名重要但也很难

要获得共识，最好要有叫的响的名号，采访里也提到 Google 的团队是很努力地才想出了 Kubernetes 这个名字。坦率说，除了含义贴切外，这个名字从长度和发音本身都不理想，所以在国内大家也习惯都叫 k8s。这点反倒是国内第一个 CNCF 项目 Harbor，起了一个很好的名字，贴切又简单。

只能说，起名真的很难，不然也不会成为计算机科学两大难题之一。

技术的角色

Infra 赛道，技术的核心主要在于工程能力，像领域建模，API 设计，系统架构和演进路线。算法在某些领域会是核心，但绝大多数时候并不如工程能力重要，而且随着项目时间的推移，工程能力会变得愈发重要。

越有经验的工程师，越知道 API 设计的重要性，而 API 则是领域建模 (Schema Design) 的外现

越有经验的工程师，越知道要 start small，get the core right first

产品的角色

Infra 产品里，技术和产品这两者是很难分开的，技术架构师也是产品经理，就像这次参加 Panel 的 5 位创始人嘉宾也都是代码核心贡献者。

Infra 里更偏产品的大致有这么二块

1. 和上下游之间的关系，和竞品的差异点。也就是找准自己的定位。
2. 面向开发者的体验。

这个很像狙击手，首先找到一个合适的狙击位置，再瞄准发枪。

技术和产品的小结

我在 Panel 里提到技术，产品都不是护城河 (moat)，只有生态才是。但前两者不可谓不重要，因为他们都是构建「理想」生态的关键路径。k8s 的 Tech Lead Joe Beda 之前是 Google Compute Engine (GCE) 的 Tech Lead。从构建容器编排系统的工程产品能力来说，k8s 的创始团队是要远远胜过同期其他团队的。

如果没有 k8s 的出现，可能现在编排系统还是一片混战。Mesosphere 占据了先发的优势，但是因为缺乏优秀的系统设计，之后还是会出现新的挑战者。可能在另一个没有 k8s 的平行世界里，一面就是建立起生态优势的 Mesosphere，一面是一个设计更好的新系统，形成一个长期甚至是永恒的僵持局面。

其实数据库领域的 MySQL 和 PostgreSQL 就是一个这样的现状，MySQL 在早期占领了生态，使得一个基本从各方面都更加优秀的 PostgreSQL 长期处于一个劣势，这几年才开始慢慢追赶上来。但业界像 Bytebase 这样需要去同时对接 MySQL 和 PostgreSQL 的局面已经无法改变了。

所幸 k8s 出现的时间点还比较早，才使得整个业界有了一套统一的云操作系统。从 k8s 如今的影响力来说，他当初的那批 founding team members 都称得上是对人类进步作出贡献的人。

Vision，勇气和执着

k8s 的开源也充满了波折，不认同的高管，毫不关心的市场团队。Joe Beda 当时在 Google 应该是 L7，即使不做 k8s，以他在 GCE 的 scope 升 L8 也只是时间的问题，却还是要力排众议，坚持去折腾一个新项目（虽然 Google 的正常技术职级能到 L10 (不算给 Jeff 和 Sanjay 专开的 L11) ，但 L7, L8 在当时的 GCP 已是很高的职级，我记得当时整个 GCP 只有一个 L8，还是从 Cloud SQL 组出去的，侧面也能看出当时公司对于 Cloud 的投入程度）。

记录片里只是稍微提了他们内部如何走开源流程的故事，我想背后的故事肯定要复杂的多。大厂里具备 vision 的技术 leader 还是有的，但稀缺的是能够把 vision 表达出来，再获得大团队 buy-in 的人才。

Vision 之上，更可贵的才能是勇气和执着。

我自己算是一个反例，因为在上家大厂也有一个遗憾，我曾经也提出过要把某款数据库开源的想法，但被主管答复了一个合理但谈不上信服的理由后，我也就妥协了。如果当初我据理力争，一路 escalate，撂下不开源自己就不干的狠话的话，可能这个事情当时也能成，也不用要 2 年多后才等到他的开源。虽然最终项目能开源还是很好，但最好的窗口已然错过了。

在接下来做 Bytebase 的过程中，还会面临很多勇气的考验，也希望自己能表现的更好一些，也不辜负前司给予我心力上的那些磨炼。

可惜的 Docker

这里说的 Docker 不仅是指 Docker 这项技术，更是指 Docker 背后的商业化公司 Docker, Inc

我是 2013 年加入的 Google, Docker 也就是前后那一年横空出世的。那时整个硅谷，做 infra 的真的是人人都在谈论 Docker，all the rage。

Docker Container 就像发明货运集装箱 (container) 一样，发明了软件交付的集装箱，而且提供了很好的开发者体验。相信当时有不少像我一样的工程师，因为 Docker Container 去阅读了讲述货运集装箱的这本书。

如果拿前面的狙击手比喻的话，Docker 就是同时满足前面说的两个条件

偏产品的大致有这么二块

1. 和上下游之间的关系，和竞品的差异点。也就是找准自己的定位。
2. 面向开发者的体验。

可是虽然 Docker 找到了一个好的狙击位置，枪法也很准，怎奈何来了另一个枪法也准，关键是位置更有利的狙击手 🤷‍♂️

Own the Experience

Docker 和 Kubernetes 之间的竞合是开源 Infra 里很好的一个商业案例，网上也有很多的分析文章，但如果要我提炼的话，竞争的核心就是一点，who owns the experience。

越往上层走就越能 own the experience。所以 Git 要有 GitLab，MongoDB 要有 Atlas，Snowflake 从 day 1 就是一个云产品 …

Bytebase 招聘页里 第一条写的也同样是 Deliver experience

未来

个人觉得 k8s 就像 Linux 一样已经不太可能被替换了，会长期地存在下去。但另一方面，虽然 k8s 的狙击位置高于 Docker，但在整个应用体系的架构中，还是偏于下层，所以应该还有更好的狙击位。让我来畅想的话，应该是围绕 Application 找位置，因为 k8s 原生一直没有去明确定义 Application 这个概念。社区里出现了如 OAM (Open Application Model) 的方案，但我个人觉得 OAM 和 Kubernetes 贴的还是太近，从 Experience 角度没有提供如 Kubernetes 和 Docker 之间这样足够的差异。

而另外的一个思路则是从应用侧出发，去靠近 Kubernetes，提供一个应用层的整体开箱即用方案。我也会持续关注这块领域，期待有刷新我认知的方案出现。

回到数据库领域，MySQL 这样的数据库引擎对标的是 Docker，各家的数据库云平台对标的是 Kubernetes，而 Application 层面，之前业界也是没有统一方案的，直到 Bytebase 的出现。

OK，回到自己的狙位。