软件架构本质上是软件维护团队的组织架构

任何软件架构，本质上都是其背后的软件维护团队的组织架构。

笔者认为，容器、镜像、容器编排的兴起，与其说是一种生产力的创新（技术创新），不如说是一种生产关系的创新：在越来越大的服务器数量面前，以前那套基于虚拟机的管理技术不再适用了，Google 需要一种少数人管理数十万台服务器的新技术，于是 k8s 诞生了。

正如软件架构本质上是软件维护团队的组织架构，运维架构本质上也是运维团队的组织架构：规模大到必须自动化，于是容器编排便自然而然地出现了。写到这里，有一种唯物史观的感觉了。

重要的不是电影拍摄(讲述)的年代，而是拍摄(制作)电影的年代。 —— 戴锦华（北京大学教授，电影评论家）

软件工程研究的对象是人

如果你设计并调整过软件团队的组织形式的话，笔者相信你一定能深刻地体会到这句话。

微服务架构最大的价值，是通过把庞大的软件开发团队进行拆分、解耦、独立组织，进而提升宏观上的软件质量，降低软件的开发成本。

宏内核与微内核

在操作系统领域，宏内核与微内核的技术路线之争一直不绝于耳，笔者跟别人不同，不纠结哪种技术路线更加正确，而是主要从组织的角度来看待这个问题。

所谓的微内核宏内核技术路线的差异，背后其实是协作方式的不同造成的：微软可以雇佣并管理庞大的工程师开发一个复杂的、功能完备的内核；而 Kernel 由于属于用爱发电，就只能守住自己的一亩三分地，把大量的系统关键基础设施让给其它的开源软件来实现；而庞大的周边软件 linus 一个人是无法掌控的，于是它们就默认运行在用户态了。

过去十几年，还是有不少组件由于性能和功能的需求从用户态成功进入了内核态的，例如 IPVS、cgroups、eBPF 等。