【1】前言

Valiant程大约 24 分钟

本篇文章为本系列文章的前言，会先谈及一些抽象的理念和观点，目的是寻找到和笔者具备共识的读者，这类读者阅读该系列文章的效用会最大。其中部分观点可能存在争议，笔者说的并不一定正确。本篇文章不会涉及具体的技术内容，具体的技术内容将从下一篇文章展开。

程序员、码农或软件工程师这个广泛意义上的岗位，由于当下的社会大分工，已经分化出了很多细分类型的职位。在这之中，有相当一部分职位被归结为“业务开发”，从事这类职位的人经常自嘲为“CRUD Boy”或是“页面仔”，原因是因为其工作职责和内容过于紧贴企业和组织的业务流程。而大部分企业组织的绝大部分业务流程，其IT数字化其实就是完成大量简单机械和模式化的CRUD操作和页面搭建，这样的工作在从业者自我眼中看起来毫无技术含量，于是产生了这一自嘲现象。

确实如此，程序化和IT数字化带来的价值本身就是高效灵活的自动化能力，任何理论上高度机械模式化的流程，最终也一定会被自动化掉，包括CRUD、模式化的页面搭建这种简单的编程工作。相信不论是前些时候出现的各类无代码、低代码平台，还是近期出现的LLM、AI相关的技术，都向我们证明了这一趋势是必然会发生的，仅仅是到来的时间早晚问题而已。

因此，肯定有很多不满足于当下做这类简单机械模式化工作的程序员从业者，希望能够跳出这种泥潭。但限于种种主观或客观的原因，他们却不知道如何或是根本无法跳出来，我写的这一系列文章，就是希望斗胆能帮助这类同行们迈出第一步。

软件工程的发展趋势

从历史上来看，生产力、技术的发展，必然都是建立在前一代技术的基础上发展的，软件工程更是如此。从最开始的机器码到汇编、汇编到高级语言，本身就是一个不断自动化和迭代进化的发展过程，并且每个技术的出现都建立在之前的技术上。同时，这个自动化和迭代进化发展的过程往往也伴随着整体生产效率的提高，同样的程序员，通过机器码和高级语言编写代码，显然是后者的效率远远高于前者。

那么，把这一发展模式套用到当下近期范围内技术的发展上，我们也会发现也正好吻合。

拿大家最熟悉的互联网web服务技术的发展来说，我们可以看到以下粗略大体发展历程：

简单静态html web
具备持久化及一定动态渲染能力的JSP/ASP式MVC架构web
前后端分离的现代web

上述过程是一个粗略的形式角度的演变历程，我们从中也可以看到在这一领域也出现了非常明显的分工演变趋势：最开始的程序员人人都是全栈（这个全栈不光包括前后端，还有测试运维等），后来因为需求驱动下的整体的技术领域不断进步，每个子领域也变得越来越复杂，于是我们现在有了前端、后端、测试、运维等等的分工。

随着时间推移，该领域进一步出现了业务和基础架构的分工，即出现了一部分人专注于实现业务，另一部分人帮助这些人更高效地完成实现业务这件事。测试和运维本质上是这样，做各类框架、三方库、中间件、运维平台、AI的专业人群也是这样。

从经济学原理上来讲，分工有利于实现整个团体的整体产出效率提高，因此这样，我们的蛋糕才能越做越大，每个人能够享受到的物质水平也才能不断提高。企业和各类岗位的出现其实就是这种分工化趋势的具体体现，同样的，如果能率先实现分工专业化，就能更快享受到这部分分工化带来的稀缺红利价值。

再回到IT和互联网行业，这样来看，广义的云计算（包括公有云和专有云）的出现就成了必然，因为本质上这也是一种分工，把IT基础设施的供给和运维分了出去。同样的，大型企业内部也开始逐渐有了做基础平台、基础架构和工程化的专门团队人员，也是顺应了这一趋势。

因此我们也可以据此推断出一个趋势，业务开发范畴内的工作将被不断分解解耦，每一块事情最终都会有专业的团队或是产品服务来承担，所以最终的业务开发，理论上只需要做业务建模和流程设计就够了。其他任何非业务本身相关的工作，都会被其他人或机器做掉，比如具体的代码实现可以交给低代码平台或AI，代码可以部署到云上由云计算厂商运行维护。

所以我们反而现在能够又能看到很多的全栈程序员了，但他们的全栈能力，离不开开发过程中每个方面、环节专业化工具效率和易用程度的不断发展，如果缺少了这些东西，他们还是只能做像是早期互联网时代的全栈，但只能搭建出非常简易的产物。全栈搭建出现代化应用程序的能力，是基础设施和专业化工具不断发展的给予的。

这一现象的本质实际上就是，在实现业务流程的过程中，每一个可能被解耦、自动化、专业化而产出价值的步骤或模块，最终都将被解耦。我们当下看到的很多开发工具，比如IDE、抓包工具、性能分析工具、可观测平台、CICD平台等等，也都是这个逻辑的例证。

那么，在这样的趋势下发展到最终，业务开发还真的需要开发人员吗？我想应该不需要了，因为只需要一些非常懂业务本身的人使用各种完善的工具就足够了，技术实现将被完全解耦掉，这也就回到我们上一节所提到的，CRUD和模式化页面搭建这类机械重复式的编程工作一定会消亡。当然，这种模式真实到来的时间到底还要多久，在当下还无法确定。

路在何方

那么，路在何方？我们如何避免被替代和淘汰？

答案是顺应发展潮流，也就是我们在上述所述的软件工程的发展潮流。

如果你是一个善于做业务建模和流程设计的人，随着你的不断发展，到了一定职场等级，你自然就不需要写代码了，而是要关注整个业务模式怎么通过最高效的方式跑通，技术上的高效只是其中一方面。在某种程度上，你就成了“专门做业务建模和流程梳理”的分工、管理专家，其实这就是现在CEO和企业管理者所做事情中的一部分，最终聚焦的技术部分一定变得很少。而要想沿着这条这条发展路径走得远，你就得逐步降低技术在你视野中的比重，去侧重更多其他领域：人际沟通、团队管理、用户管理、商业模式及市场理解等等，这些能力是你在业务路线进一步发展的必要条件，并且这些能力必须要提升到足够优秀的程度（否则根本无法从激烈的竞争下脱颖而出）。如果你不能提升这些能力到一定水平，还限于技术一隅之地中，必然会被无情地淘汰掉。

当然，这种模式是很好的，但未必适合所有人。因为这首先要求这个人要有发展这些能力到一定水平天生的潜质（往往在大学和职场早期就能表现出来），其次TA本身要想并乐意成为这样的人，最后还得抓住稍纵即逝的机会做出关键的成绩、从一群人的激烈竞争中卷上来，这并不是所有人都能做得到的。

而如果你更希望继续做技术、发挥你积累和所学的计算机及软件工程专业背景的知识呢？当前情况，有两个方向：

向更专业分工化的职位方向转移，做给技术本身提供加速度的技术：比如现在的AI、芯片、操作系统、基础平台、各类基础软件的研发等等。但同时这些技术都是有门槛的，往往需要垂直领域下非常纵深的知识和经验，往往得有一定时间的积累、天赋和契机才能进入，直接的切入也是不现实的。
向更广泛全局化的技术架构方向转移：能够设计和实现一个完整的业务系统架构，同时要能够满足各类性能、稳定性、灵活性要求，而不仅仅限于实现一隅业务逻辑模块。这种职位所要求能够胜任的人必须要足够广且一定程度深的知识经验，在每个方面都有一定积累，才能达到设计并引领实现一个卓越系统架构的要求。

这两个方向一个偏垂直方向的深度，一个偏水平方向的广度，每个人都有适合的发展方向。而这两个方向也有共同的基础要求，就是得有牢固的基础知识和丰富的工程化经验：

基础知识无非就是CS专业所学的那些核心专业课，但这些理论必须被大量且充分的实际实践和经验所印证，达到融会贯通的程度，而非是仅限于课本和面试八股文式的字面理解；
工程化思维就是在具体的工程实践中靠不断的经历、反思、学习和总结，所得到的隐性和抽象化的观念、思维习惯和态度，其实就是工程师的核心能力：所谓的“解决问题的能力”；

从程序员的本质特性上来说，计算机科学相关的知识、系统设计能力、工程化思维等等特质是这一群体的差异性特征，也是我们相对于社会中其他分工职位的突出优势。并且这些特质并不会像各类新潮的上层技术、框架和工具频繁地迭代和变化，这无疑保证了我们也能随时间成长，建立越来越大的竞争力。

这顺应了整体的行业发展趋势，因为增量的蓝海业务不是时刻都有的，大量流水线工人式的程序员的需求也并不稳定，但对核心能力高要求的高级岗位还是能够稳定存在的，这点我们去看当前的美国大厂内资深技术人员的状态就能明白；
同时，这些基础要求对应的能力在技术领域的可迁移、泛用性和耐久度都是很高的，并不像特定编程语言、框架、工具或是三方库的熟悉和掌握，这些东西的价值可能两三年就会归零掉，同时还带来了频繁的适应成本。并且这些技术能力往往能帮你更快地熟悉和掌握这些上层语言、工具或框架地使用。

因此，我们的发展思路一定是基于自身的差异化特质和优势去制定的，从这个角度来看，对希望继续做技术的人来说，进入到对这类知识和能力水准要求更高的领域和位置，才是我们应该前进的方向。

当然，选择了技术方向，同样也要求你有天赋、热情并且能抓住机会。

脚踏实地

那么，从抽象的宏观角度回到现实的微观角度，对于当前正在做业务开发的从业者，想要进一步发展，具体能做些什么？

如果你更喜欢做业务，更有这方面的天赋，就去更深地理解业务，训练你的软能力，最终弱化技术比重，转型成为业务专家即可，这条路并不是我们讨论的重点。

而如果你更喜欢做技术，就要侧重训练和提升在上一部分提到的那些基础能力。

首先一定是扩展技术视野，去涉猎更多更专业的技术领域，逐渐从当下简单繁琐机械的工作解脱出来。比如，你对前端领域更感兴趣，就去接触更专业的前端工程化、框架、技术和专业化含量更高的垂直领域如数据可视化等等；如果你对服务端、运维领域更感兴趣，就去探索技术和专业化含量更高的基础软件（数据库、OS、编译器）、中间件、分布式、云计算、K8S&容器等更专业化的领域。最好先从和你比较接近的领域开始，这样阻力最小。

然后在广泛涉猎的基础上，找到你认可的若干个专业领域方向进行深度积累，不断打磨你的核心能力。

这些领域往往更为贴近底层，能够帮你融会贯通所掌握的基础知识；这些领域也是高质量工程化实践的成果，在这些领域的学习，也能帮你更深刻地理解进而积累学习到资深专家所具备的工程化思维。

因此，我们也可以看到，这恰好满足了我们在前面提到的技术路径上持续发展两个方向的共同交叉基础要求。

这也就到了本文要说的主题：为什么要写这个系列的文章？

我希望提供一些和上述领域相关的内容，抛砖引玉，帮助、引导和激发希望在技术发展上有更宽更远发展的从业者更进一步。而我选择的第一个内容方向便是容器&K8S技术生态领域，作为一个有多年基础设施、架构及平台从业经验的技术人员，在这些年的发展中，我深刻地认识到近十年范围内发展速度最快、生态最为繁荣的就是该领域：

这个领域的技术衍生、影响和支持了很多周边领域的发展，包括：上承分布式、微服务、云计算、云原生、AI模型训练和推理等新兴技术形态，下接操作系统、网络、存储及各类基础软件中间件等等。因此，通过了解这一领域，你能够将其作为跳板基础，更轻松地切入到其他更专业的领域内；同时也能先广泛地对很多新兴和高技术含量的领域有所了解，提升你的技术视野。
这个领域和业务足够接近，做了一定时间的业务开发同学应该都有机会了解和接触到，这无疑是一个很好地知行合一的过程，比起那些很少接触的所谓的底层硬核领域，这一领域处于的相对的中间位置，从能够让自身触及到的领域切入显然更为简单。
这个领域是近年软件工程高质量发展的代表领域，无数的大中小公司的杰出人才，出于盈利或非盈利目的，通过开源或闭源各种形式，为这一领域贡献了大量高质量代码。这无疑是一笔宝贵的财富，我们能从中学到很多资深专家的工程化经验和思想，以支撑我们在其他任何领域的长远发展。
在近十年范围内，IT技术的一个主要的发展趋势在此领域，即使你不主动了解，总有一天也得被动了解，因为其代表了达成更先进生产力的方向和可能。对该领域有一定程度哪怕并非深入的了解，也能助力当前业务开发工作本身的效率：试想你所在的公司已经或将要使用该领域技术进行技术栈改造，若有了解你就有优势；跳到其他公司，如果其他公司使用了这一技术领域的技术栈，你也能更快融入；在日常开发中，该领域的技术生态中各类丰富的项目、工具和范式也能提高你开发工作本身的效率；

可以说，对这个领域的了解和涉猎，是突破当前舒适区、谋求更为长远发展的很好的开端，我希望通过一系列文章，来帮助感兴趣的读者踏出这一步。

2.自我背景介绍

那么，既然你有兴趣阅读到这里，我们一定有一些相似的观点和想法，请允许我做一下自我介绍：

我是Valiant程，在多个云计算厂商、互联网公司的基础架构和平台部门及团队有多年的开发和实践经历。

诚然，作为常年在基础、底层团队内的角色，我们也有自己的焦虑：在公司濒临倒闭的情况下，基础架构团队无疑会比核心业务团队更先被伤害；我们这类职位的跳槽选择和坑位少；经常自嘲或被嘲为“客服”，要做很多繁琐的答疑和支持工作；作为基础团队支持着大多数业务，可能会成为7 x 24h oncall苦命人等等。

但我们还是做下来了，并且，作为对技术有一些热爱和追求的人，怀着凡事刨根问底的研究和探索精神，在这个岗位中还是能感到开心和满足的，因为还是能遇到一些机会满足我们对技术的追求和探索欲的。我们深知没有完美的工作，既然是受雇佣做事，拿着工资，那么在这个过程中有一点开心和满足，都是值得的。

同时，在工作的这些年里，我也接触了很多如前文所述的业务开发方向的从业者，他们常陷于在之前所提到的焦虑中，但自身又无法思考出可行的方式去解决自己的焦虑和困境。

我常常和他们互相交流这方面的事情，发现他们总是认为未知的领域是艰涩和难以切入的，一方面待在自己的舒适圈内焦虑，另一方面又惧怕跳出舒适圈面对的未知和不确定性。

有的同学能跳出来，有的却迈不出这一步，但最终每个人都会得到他做出选择对应的结果。

作为在这个更深领域做过一段时间工作、有一些浅薄经验的人，在我所处位置的视角下，我认为这些看似好像晦涩和高深的领域，其实并不难，只是因为很多人缺乏场景和实践驱动，缺少一些必要的观念，迈不出第一步去了解。

我希望通过写文章的形式，去帮助那些抱有类似焦虑的但我无法在生活中实际遇到的人，可能他们已经有了这样的意识，但是找不到途径。同时，我也深知自己知识和见闻的局限性，帮助更多的人，同时也是帮助我自己，我也希望从文章读者的反馈中，同时突破自己的舒适圈，学习更多我所不知的知识、经验和观点。

3.本系列文章的受众和边界

我所写的本系列文章，会聚焦于业务开发视角下的K8S&容器生态技术一览，期望读者应该对该领域没有体系化的了解，或是仅仅限于浅尝辄止的听闻和接触，如果有涉及到这个领域的同行，也可以选择性地参考下，并为我做指导修正。

本系列文章并非服务以下目的：

面试、八股文：当然，你阅读这些文章肯定会对面试有所帮助，但我的目的并非是提供八股文套路以帮助应对面试，而是希望真正地让你从一定广度和深度层面了解这个领域的思想，并接触和了解到其他相关联的更多更为丰富的领域，帮助你长远发展；
专业领域的深度分析：K8S&容器生态技术近年的发展非常繁荣，在这个领域有很多出色的工程师都在其中从事令人钦佩的工作，他们的专业性是母庸置疑的。其中很多人也会积极产出非常具备深度的文章，这些都是想要深究可参考的资料。因此，我并不会涉及该专业领域的深度分析，整体内容会轻细节和实现，重思想、架构和模式，并且尽可能让更多没有背景的人读懂；
如何具体部署/使用：作为业务开发，一般会直接通过PaaS类的平台使用K8S&容器，不会直接参与部署和使用；如果想学习具体的部署和使用，网上的相关文章也非常丰富，如果读者需要，可以自行查阅学习，我的文章则会更加侧重于思想和架构上的解释和分析。其实明白了这些思想和架构，具体的应用和操作其实是一件非常简单的事；

当然，该领域的科普文章也相当多，我会从个人独特的视角出发来提供内容，你可以结合多个作者的视角来综合形成自己的认知，我的不一定是最正确和权威的。

除此之外，出于前面提到的目的，我期望后续做一些其他更广泛和深度性的技术领域的文章产出，持续提供更多具备价值的内容。本系列文章是我第一次的尝试，后续做哪些方面，认可我观点的读者也可以积极反馈。

读者能够获取什么价值

个人角度
1. 扩展技术视野，接触更多更新更有深度的技术，提高个人技术竞争力
2. 以该领域为跳板，找到适合自己深耕的专业技术方向，谋求更长远的发展
3. 从该领域庞大且高质量的代码和项目中学习高超的编程技巧、设计思想和工程化思维
4. 通过K8S&容器生态技术领域的特质，对特定方面的底层基础知识加深理解和贯通
5. 了解K8S&容器生态技术领域中的范式和工具，提高自身的工作效率
6. 对于已实践相关技术的公司，帮助你更高效地理解和利用公司搭建的基础平台，加速个人发展
企业和组织角度
1. 如果你能在某种程度上影响企业和组织的技术选型，将K8S&容器生态技术应用到企业和组织的技术栈中，或是改进使用这类技术的方式，便能够为你的企业组织带来更高效的产出和更低廉的技术成本
2. 通过接触更前沿的技术生态，能够提升整个企业和组织的技术专业性

作为受众，我应该着重了解什么

该领域技术的发展历史、上下文背景、在整个IT互联网技术链条中所处的位置，为什么会出现这个领域的技术
业务开发如何和该领域技术产生关联
该领域技术关键代表性的思想和设计理念
该领域技术所包含思想对业务开发本身的作用和启发
该领域技术在整个计算机IT技术大图里的位置、关联技术领域
针对本系列文章的受众，对该领域技术的细节和实现的细致了解是非必要的（譬如源码阅读和解析）。当然，如果读者自身产生了好奇心，可以进一步自行了解，网络上有很多优秀的深度解析文章

4.本系列文章的大纲

大体的大纲结构如下，可能会随着我文章的编写而微调：

前言（本文）
容器的诞生背景&发展历程
K8S的诞生背景&发展历程
K8S&容器生态技术与业务开发的关系、具体交互模式
容器技术架构：基本原理&关键流程
容器技术设计思想及范式漫谈
K8S技术架构：基本原理&关键流程
K8S技术设计思想及范式漫谈
K8S&容器生态技术与其他技术领域的关联
K8S&容器生态技术相关生态、未来发展演进趋势

5.尾声

本篇文章到此就结束了，在本文，我花了大量篇幅讲了一些偏抽象和上层的东西（可能也有人会认为是“废话”）。但这样的做的目的也和我个人的理念有关：我认为具体做一件事情之前，一定要把动机、目的和需求搞清楚，如果这些东西没搞清楚就贸然上手，最终很可能会浪费掉很多时间精力。而这些浪费，如果事先有所考虑的话，都是可避免的。

就像在实现某个技术需求时，如果没有先做设计，上来就写代码，虽然快，最终还是避免不了去做重构，耗费的时间反而会比先做设计再实现所花费的时间更长。

如果你认可我在本文所述的思想和理念，那么请对我之后的文章保持关注。除此之外，如果你有其他相关问题想和我交流讨论，可以积极留言反馈，我会认真思考并回复大家的意见和问题。

从下一篇文章开始，我会具体讲述K8S&容器生态技术领域的内容。

文章编写难免可能存在疏漏，愿意接受不同背景的读者做出批评指正。

如果阅读到的文章对你有所帮助，欢迎分享给其他可能用得到的人。

‍

Valiant程