架构师（2022年11月）
架构师 2022年11月刊 本期主编褚杏娟 流程编辑丁晓昀 发行人霍泰稳 反馈feedback@geekbang.com 商务合作hezuo@geekbang.org 内容合作editors@geekbang.com CONTENTS/目录 热点|Hot DevOps已死，平台工程才是未来 上云“被坑”十年终放弃，寒冬里第一轮“下云潮”要来了？ 那位用Rust重写数据库的创始人来复盘了：删除27万行C++代码，值吗？ 理论派|Theory 字节大规模微服务语言发展之路 去哪儿网ServiceMesh落地实践：100%容器化打底，业务友好是接入关键 推荐文章|Article 新一波JavaScriptWeb框架 字节跳动开源BitSail：重构数据集成引擎，走向云原生化、实时化 观点|Opinion 当“增加人员”不足以解决问题，你就该考虑应用“微前端”了 卷首语 专访“MySQL之父”：要拥有一份能做一辈子的开发工作，需要给自己积累名望 作者：李冬梅 “热爱”，是贯穿于“MySQL之父”Monty过往40年编程人生的关键词。 60岁的Monty现在仍在写代码，每周保持60个小时的高工作强度。他说，等到80岁时，才会考虑将工作缩短到35小时。编程这事儿，他还要干一辈子。 二十年磨一剑 InfoQ：您在34岁时开发出了MySQL。从接触编程到开发出MySQL，这段时间可真不短，您都做了哪些工作？ Monty：我从18岁的时候就开始编写MySQL的最早一批代码了，这部分代码主要是 MySQL内存控制方面的，所以最早的开发工作可以追溯到1982年左右。 后来的开发工作都是以之前的成果为基础。在此期间，我也开发过不少硬件驱动程序，设计了一款不错的处理器，还做过很多游戏。 InfoQ：这么长的开发历程，是什么让您一直坚持了下来？Monty：我想，是热爱。我喜欢做开发，我特别喜欢解决问题的感觉，特别是在开 发MySQL和MariaDB的过程中。而且，我参与了开源，帮助很多人走向成功。我觉得这一切都能让人始终保持热情。 InfoQ：从您写下第一行代码到开发出MySQL，花费了近二十年时间。但目前市场上也有不少企业投入过十年甚至十五年来开发软件，但最终成果从来没能真正流行起来。你怎么看待这样的现实？ Monty：我确实是用了快二十年才开发出MySQL，但当时我没有想到未来这个软件会发展成什么样子。我将我的软件卖给了北欧最大的一家电脑公司，但后来，我的软件成了整个平台上最受欢迎的产品。 你提到的这种情况也的确存在，很多公司耗时耗力，最终却一无所获。MySQL的成功是与时代背景分不开的。当时互联网已经得到广泛认可，每个人都需要这样的数据库，用它创建互联网所需要的数据。当时那些技术巨头还不看好互联网，所以这是个有待开发的蓝海市场。 其实只要意识到需求的存在，其他的就都好办了，所以我从94年开始正式编写MySQL。最终成果的发布大概是在95年末，也就是说，我们用了短短两年就开发出了MySQL的第一个版本，成为当时的新兴支撑性产品。 InfoQ：技术圈内，您被誉为“编程天才”，您怎么看待这样的称呼？Monty：我觉得差不多，我在编程方面确实有点小天赋。InfoQ：我想不只是编程这一个领域吧，您在创业方面也很成功啊。 Monty：嗯，我在企业家、开源倡导者、程序员和架构师几个角色上表现得都还可 以。 InfoQ：您是否会认为，如果一个人想在某个领域取得卓越的成就，天赋是不是比努力更重要？ Monty：那是肯定的。毕竟在编程行业，一个优秀的程序员要胜过十个普通的程序员。这种优秀，源自天赋、努力工作，更源自想要了解一切的学习精神。 所以在前二十年里，我每天基本上就是学习计算机、学习硬件、学习如何高效编程，学习怎么让计算机发挥出一切性能。有了这样的底子，我才能真正开始做自己的事。 转管理，不是程序员的尽头 InfoQ：从MySQL到MariaDB，您已经证明了自己是位成功的企业家。但不是所有技术人员都能成长为管理者，在这方面您能不能分享一点经验？ Monty：我觉得大多数开发人员就适合当开发者。 我知道，一直都有些开发者屈服于现实，转而去做管理岗。但根据我的观察，他们大多数人的编程才能其实比管理才能要强得多。很多人就是为了钱，管理岗的收入应该是比开发者要高一些。 但我觉得他们的天赋主要还是体现在开发上，最好能坚持下去，依靠自己的才能走向成功。 InfoQ：您在34岁，也就是快接近中年时才开发出MySQL。但在中国市场，35岁以上的开发者往往会考虑转向管理岗。您怎么看待这种现象？ Monty：我认为不应该这样。因为好程序员，特别是优秀的程序员其实更难找。虽然管理岗的薪水可能稍高一点，但却很容易被取代。所以只要大家有天赋，最好能坚持在技术的道路上走下去。 至于MySQL这边，其实我从来不想当CEO。我想做的是CTO，负责技术方面的工作，毕竟我的天赋就在技术上。我觉得自己没有那份成为优秀全职管理者的天分。 我把一生都投入到写代码上，我喜欢这活儿，也正是编程让我成为了独一无二的人。 InfoQ：如您所说，转到管理岗后，就会得到更多资源，比如晋升机会更大、薪酬更高。相比于技术理想，这是很现实的考量，毕竟大部分人要养家糊口，您怎么看呢？ Monty：我觉得很多企业在职业设计上都有这种错误。所以在MySQL和MariaDB，我觉得与其靠让大家做管理来提升薪水，不如让他们承担起更多责任。有时候，职位的重要性比单纯的高薪水更有吸引力。这可以算是另一种思路吧。 大家当然应该为自己的编程事业规划一条职业发展道路，但没必要把转管理岗当成唯一的方向。企业不需要那么多经理，而且在开始裁员的时候，管理岗都是最先倒霉的。毕竟经理人很容易替代，但优秀的程序员不可替代。他们掌握着企业最需要的代码知识，所以只要代码在，那岗位就在。 编程40年，如何保持技术前瞻性？ InfoQ：您的编程经历大概有四十年了。在这么长的从业过程中，您是怎么保持自己的技术前瞻性的？ Monty：我的办法是信任客户。我的想法一直很坚定，那就是跟客户合作、解决问题，了解他们未来可能遇上的新问题，再共同将其克服。 所以只要有了良好而且足够广泛的用户群体，比如MySQL和MariaDB建立起的客户基础，那他们就能告诉我，未来会走向哪里。 我在等待未来的到来，同时也成为造就未来的一部分。所以，认真倾听客户意见，与他们合作，自然就能了解最新的技术。跟客户距离越近，我们就越了解功能需求，并据此安排自己的工作。 对于开发者，我们要做的是为他们提供正确的技术、让他们满意。总之，只要明确了需要解决的问题，技术选型自然就会容易得多。 InfoQ：那您会常跟社区中的开发者讨论技术问题吗？Monty：我经常参与技术会议，在那里跟与会者们交流。这也算是一种探讨吧。 另外，在接触世界各国的客户，比如中国的客户时，也可以跟内部员工讨论关于 MySQL和MariaDB的问题。他们代表的就不是客户，而是社区成员。所以我会认真倾听。 InfoQ：对于想要学习MariaDB或MySQL的中国开发者，您有什么建议吗？Monty：首先应该积极参与到社区当中，帮助他人、改进实现。如果你需要某项功 能，就想办法着手开发，并随时向MariaDB#基金会寻求帮助。我们可以帮助大家，告诉你具体该怎么做。你审查过自己的代码吗？你也可以参与审查其他贡献者的代码，这就 是实实在在的开源贡献。 而要想成为一名出色的程序员，拥有一份能做一辈子的开发工作，那最好能让自己积累起名望，让自己在开源世界拥有一席之地。有了这些积累，就不是你找工作，而是工作来找你了。保持住好奇心，积极探索事情是如何运作的，这样我们就会变得更好，对企业的价值也越大。 本文节选自InfoQ《专访“MySQL之父”：我曾创造MySQL，也将颠覆MySQL》 DevOps已死，平台工程才是未来 作者Tina平川 开发者不想做运维，对DevOps来说不是好事情。 最近，ScottCarey发表了一篇调查文章，喊出了一些开发者的心声：“扯淡的DevOps，我们开发者根本不想做运维！”除此之外，软件工程师兼DevOps评论员SidPalas也在推特上写道，“DevOps已死，平台工程才是未来。” 他的核心观点是：开发者不想跟基础设施打交道，企业在发展过程中又需要控制自己的基础设施。只有平台工程，能将这两个相互矛盾的命题统一起来。 Honeycomb的首席技术官CharityMajors对此也有同样的观点，她认为在软件演进过程中，我们将运维技能从开发技能中剥离出来，形成了两个不同的职业，但结果证明这是一个巨大的错误。因此DevOps出现了，我们用它来重新统一开发和运维。然而开发周期应该是一个企业中最稀缺的资源，所以应该将尽可能多的资源花在核心产品上。 Majors认为，在过去，有的工程师写代码，有的工程师跑代码。而现在，工程师不仅编写代码，还要运行他们编写的代码。这导致软件工程师觉得他们必须对所有事情都了如指掌，大大增加了“认知负担”。 这迫使许多团队重新在自动化带来的自由与认知负担之间进行权衡。平台工程也因此越来越受关注和热议。PlatformCon是第一个面向平台工程师的会议，一出现就吸引了 超过6,000名与会者。Gartner也在其2022年8月发布的软件工程炒作周期中添加了“平台工程”（图中第四个小圆点）。 什么是平台工程？ 按照“平台工程”社区主要贡献者和Humanitec的产品负责人LucaGalante的说法，平台工程是一门设计和构建工具链与工作流的学科。这些工具链和工作流可以为云原生时代的软件工程组织提供自助服务功能。平台工程师提供集成化产品，通常称为“内部开发平台（InternalDeveloperPlatform）”，可以涵盖应用程序整个生命周期的所有操作需求。 内部开发平台（以下简称IDP）是位于工程团队已有技术和工具之上的一层。它帮助操作人员进行系统性设置，并为开发人员提供自助服务。平台工程做好了，就好比是为个体开发人员铺就了金光大道，他们可以从IDP层获得合意的抽象等级。 从DevOps余烬中崛起 DevOps和云原生的概念兴起之后，似乎是在突然之间，工程师们不得不掌握10种不同的工具、Helm图表、Terraform模块等，仅仅是为了在多集群微服务设置中的多个环境中部署和测试一个简单的代码更改。问题是，在整个工具链的演进过程中，这个行业似乎认为，在全球经济的几乎其他所有领域都被证明有效的劳动分工（Ops和Dev）并不是一个好主意。相反，DevOps范式备受推崇，被视为实现高效设置的方式。 开发人员应该能够端到端地部署和运行他们的应用。“谁构建，谁运行”，这才是真正的DevOps。这种方法的问题是，对于大多数公司而言，这实际上并不现实。 虽然对于像谷歌、亚马逊、Airbnb这些比较先进的组织来说，上述方法很有效，但对于其他大多数团队而言，要在实践中复制真正的DevOps并不简单。最主要的原因是，大多数公司都没有像他们那样的人才库，也不会仅仅为了优化开发工作流和体验而做他们那样的资源投入。 与此相反，当一个普通的工程组织试图实施真正的DevOps时，往往会出现一系列的反模式。我们通过一个例子来看下，当组织决定实施DevOps并取消正式的Ops角色或团队时，许多开发团队中出现了什么情况。开发人员（通常是比较资深的）最终承担起了管理环境、基础设施等的职责。这就导致了这样一种情况：“影子操作”由那些在编码和产品开发方面才能体现出最大价值的工程师来执行。没有赢家。高级工程师现在要负责设置，并需要处理比较初级的同事的请求。在组织层面，其最昂贵和最有才华的资源现在正在被滥用，他们无法再以同样的速度和可靠性来交付功能了。 这类反模式已经为许多研究所证明，比如Puppet的DevOps现状报告或是最近Humanitec的基准测试研究。后面这份
