乌托邦式“直接迁移上云”？MongoDB CTO：现实可能不遂人愿

自诞生以来，MongoDB 凭借灵活的文档模型、可扩展性和高可用性等优势获得了无数开发者的支持，并一直在 DB-Engines 排行中占据着所有数据库前五、文档型数据库第一的位置。

作为关系型数据库强有力的挑战者，MongoDB 以一种实用且可扩展的方式充分发挥文档模型的全部功能，改变了数据库本身，被很多人认为是行业内的一次重大变革。过去这些年 MongoDB 一直走在数据库技术的前沿，其发展过程中具有里程碑意义的事件包括：2015 年收购 Wired Tiger 存储引擎，带来存储层的重大改进；2016 年推出 MongoDB Atlas，开始提供数据库托管服务；2018 年发布新版本，可支持 ACID 事务；以及 2020 年宣布支持全球多云部署。

此外，在云厂商与开源厂商之间利益冲突开始白热化的 2018 年，MongoDB 率先修改开源许可协议，把开源许可从 GNU AGPLv3 切换到 SSPL，引领了一波通过修改开源许可重新定义与云厂商合作规范的潮流。

近日，围绕数据基础架构的技术趋势、数据库上云、云数据库、云厂商和开源厂商之间的关系等话题，InfoQ 有幸对 MongoDB CTO Mark Porter 进行了一次专访，请他跟我们分享他在数据库领域从业三十多年对技术进展和趋势的洞察，以及他从 Tech Geek 一路成长为技术管理者、CTO 沉淀的思考和经验。

MongoDB CTO Mark Porter

在 Mark Porter 看来，MongoDB 是过去十年来数据库技术领域规模最大、最重要的一次转变，对 MongoDB 本身而言，其最重要的里程碑节点就是现在——向完整应用数据平台的转变。此外，他认为今年开源厂商和云厂商之间的关系发生了重大变化，正在从亦敌亦友的关系转为朋友关系。Mark 表示，“MongoDB、Confluent 和 Snowflake 等第三方厂商正在崛起，并且都在创造最佳性能的软件。云提供商越来越意识到，他们的工作就像是建造房屋，确保房屋拥有充足的电力供应、完善的管道系统和全面的安防措施；但是，人们不会找云提供商来为其制作家具，诸如沙发、橱柜等漂亮家具的制作通常由 MongoDB、Confluent 和其他公司来完成。云提供商有了这样的认识，而我们也开始与 AWS、谷歌云（Google Cloud）等美国大型云提供商，以及阿里巴巴、腾讯等中国本地云提供商建立良好的合作关系。”

以近期关注度颇高的 Serverless 数据库为例，MongoDB 在 2021 年全球用户大会上发布的 Atlas 无服务器实例公开预览版，就是基于 AWS Lambda 打造的。据透露，其将在 6 月的 2022 MongoDB 全球用户大会上 GA。

关系型数据库诞生于 20 世纪 70 年代，当时构建数据库最大的障碍还是存储成本。高昂的存储成本让人们望而却步，于是转而寻找一种高效的数据存储和检索方法，而最好的方法就是将数据存储在数据库表中。50 年后的今天，存储成本实际上已接近于零，如今组织面临的最大障碍是开发者的工作效率和能力。

近日，MongoDB 发布了《2022 MongoDB 数据与创新报告》，该调查报告是一项针对亚太地区 2,000 余名（包括中国 400 余名）开发者、IT 决策者等专业技术人士的详尽调研。调查报告显示，高达 92% 的受访者认为定期构建新的应用程序和功能是企业获得长期成功的关键，但许多机构认为能真正用于创新的时间非常有限，IT 专业人员在现有数据、应用程序和基础设施维护方面所花费的时间（27%）与用于构建全新的增值功能或应用程序的时间（28%）基本相当。

此外，调查报告指出，中国企业普遍认为技术创新对于推动未来增长至关重要（80% 以上的中国受访者持此观点），但 47% 的受访者认为其组织机构的数据架构较为复杂，而 61% 的企业表示复杂的数据基础架构阻碍了创新的进程。

在 Mark 看来，有很多因素可能导致数据基础架构的复杂性，其一是许多组织仍在使用过时的传统技术，增加了软件开发的复杂性；其二是大型企业可能拥有成百上千个应用程序，而每个应用程序都拥有各自的数据源和数据管道。

随着时间的推移，数据存储和管道成倍增加，组织的数据架构也变得愈发复杂。由于应用的技术各不相同，且每一种技术都有自己的框架、协议，甚至是语言，基础架构的扩展变得极其困难，因为每一种架构都是定制的，且极易出现问题。团队不得不把宝贵的时间花在集成工作上，没有多余的时间来构建企业真正需要且客户青睐的新应用程序和特性上。

而这就是所谓的创新税。在很多情况下，创新税表现为对新技术的抵触，因为底层架构太过复杂且难以维护，更不用说理解和转换。Mark 认为，企业需要采用新的方法来解决问题。

他提出了一个应用架构“新的第三层”的概念。过去，我们采用“客户端 / 服务器 / 数据库”或“展现层 / 应用层 / 数据层”的三层逻辑区分形式，而开发者的关注点大多放在前两层。事实上，开发者还必须在第三层（即，数据层）完成大量工作。尽管他们不需要操作、移动或管理数据，但却需要准备、连接和维护第三层中的所有数据。但现在情况已经截然不同。

如今，开发者需要的是一个能够涵盖更多功能的第三层，但是要在不增加复杂性的前提下实现。

虽然那些拥有数百种服务资源的云提供商正在尝试提供这些基础服务，但 Mark 认为，云提供商只能为开发者提供工具箱和部件，却无法提供设计完善的集成式套件，无法满足开发者在专注业务逻辑和构建应用程序过程中的需求。

Mark 认为应从完全不同的角度来解决第三层面临的问题，比如依托 MongoDB 等新型软件平台重新设计第三层，将开发者所需的所有任务关键型功能都纳入其中。即，将数据库作为切入点，采用开放标准、集成且可组合的方式，向第三层添加内置搜索、移动端同步、可视化、流处理、分析及开发者需要的所有其他功能。

Mark 表示，向完整应用数据平台转变是现在 MongoDB 最重要的里程碑节点。“为了实现这一转变，我们专注于简化 MongoDB 集群和数据湖之间的数据迁移，以及 MongoDB 中的数据导入与导出。例如，为了免去建立、管理和升级独立搜索集群的繁琐操作，我们直接将 Lucene 开源搜索工具添加到后台引擎。现在几乎每个应用程序都需要用到搜索功能，有了 Atlas，只需点击几次或单个 API 调用即可创建搜索索引。未来，我们预计会推出更多类似的以标准为基础且可组合的功能套件，以便人们轻松地将这些套件集成到其工作流系统的任何位置，例如记录系统、物联网数据着陆点或公司客户及供应商的 360 数据接收器。这一切的核心就是简化构建程序。”

前文的调查报告还提到一点，45% 的受访者表示，迁移到云端有助于简化其数据架构，而 36% 的受访者则表示，上云实际使其数据架构变得更加复杂。上云到底是简化数据架构还是增加复杂性，不同企业有截然不同的体验，这背后的原因值得探究。

Mark 表示，如今开发者需要在各种不同类型系统中使用大量的技术、数据模型、应用程序编程接口（API）和编程语言，来满足用户对现代应用程序中事务、搜索和分析功能的需求。虽然云计算给科技行业带来了革命性的变化，提供了低廉的入门成本和无限的规模以及其他各种显而易见的优势，但大多数云迁移仅复制了传统数据中心的复杂性和弊端。

对于那些确实有必要迁移到云端的应用程序而言，“直接迁移上云（lift and shift）”听起来是一个不错的选择。然而，这些迁移很大程度上只是将团队必须在本地完成的工作复制到了云端。以数据库为例，开发者仍需处理多种类型的数据系统，才能满足企业所需构建的事务、操作和分析需求。

在 Mark 看来，“直接迁移上云”并不能解决团队结构或操作流程效率低下的问题。在面对各种请求时，开发和运营团队往往各自为营、束手无策。这样一来，应用程序交付时间很难得到改善。除非面临紧急事件，例如数据中心租约即将到期，否则，“直接迁移上云”不仅耗资巨大，还会给公司带来诸多麻烦。即便完成了“直接迁移上云”，既有的应用程序也并未发生改变，依然无法满足企业对敏捷性和速度的需求，区别只在于这些工作都被迁移到了云端。

这种情况下企业将无法运用云原生的种种优势，如弹性，也无法运用云厂商和 MongoDB 等 SaaS 厂商通过大量投入所获得的可靠性、安全性和合规性。Mark 认为，“直接迁移上云”带来的成本和破坏对于企业的发展几乎没有任何助力——客户无法从中获得任何益处，企业也几乎没有获得任何优势。

Mark 认为，企业在上云方法上需要另辟新径。“我们看到，一些最具创新性的企业对应用平台进行了战略投资，从根本上改善了四大关键领域：1）提高开发者的工作效率；2）优先考虑使用优质且可重复使用的架构；3）轻松保护数据安全与隐私；以及 4）采用既兼顾灵活部署能力又侧重于多云模式的新方法。”

Mark 自称 Tech Geek，他从 11 岁开始就对技术有了浓厚的兴趣，那时候他的编程工具是一台 4K Radio Shack 电脑，14 岁时换成了惠普 64K 计算器。对编程的热爱很快成为了他的职业，Mark 整个青少年时期都在从事培训和咨询工作，他的第一份主要工作来自美国教育部，大一和大二期间，他编写了一套有关授课系统的课程，帮助位于偏远农村地区的阿拉斯加土著居民学习如何成为律师助理或会计。这让那些没有机会接受高等教育的居民能够获得职业培训，并在现代社会中取得成功。这套课程是在 Apple II 电脑上用 Pascal 语言编写的。

在 Mark 的职业履历中，数据库是非常重要的关键词之一。在加入 MongoDB 之前，Mark 曾担任 Amazon Web Services 的总经理，负责领导关系数据库服务 (RDS)、Amazon Aurora 和 RDS for PostgreSQL、AWS 数据库迁移服务以及 AWS Schema Conversion Tool。更早之前，Mark 在 Oracle 工作了 12 年，在那里他从事 Oracle RDBMS 相关工作，管理 Oracle RDBMS 服务器开发团队，担任 Oracle Corporation 工程副总裁并直接向 CEO Larry Ellison 汇报。

在很长一段时间里，Mark 都是关系型数据库的拥趸。2019 年 10 月，Mark 和一位同处在关系型数据库领域的朋友促膝长谈时意识到，在自己已经在数据库领域工作了三十年的当下，开发人员使用数据库时仍然会遇到很多困难。数据库的扩展和分发依旧挑战重重，这令 Mark 感到十分沮丧。一年后 Mark 被邀请加入 MongoDB 的董事会，他得以有机会全面了解 MongoDB 的强大之处，包括 MongoDB 的文档模型、可扩展性和高可用性等，Mark 认为这让他的思维方式变得更加开阔。

如今作为 MongoDB 的 CTO，Mark 也面临着新角色带来的挑战。在他看来，MongoDB 正处于时代和市场的十字路口。虽然他认为 MongoDB 的技术领先于大多数竞争对手，MongoDB 的软件运行范围更广，开发者能够借助现有技术更好、更快地完成开发工作。但他同时也认为，MongoDB 的这些能力和效能无法在 2022 年得到充分推广和宣传。

“我们面临的真正难题是，我们接触到的人对于 MongoDB 产品的了解程度并不相同——有的不了解我们的数据库拥有与关系型数据库同样可靠的 ACID 事务处理能力，并且支持完全分布式读写操作；有的不了解我们可以为其提供更优秀的编程方法。因此，在接触这些客户时，我必须不断地转换角色。每接触一位客户，每发表一篇论文，每进行一次会议演示，我都会遇到对 MongoDB 了解程度各不相同的受众，因此，我需要不断切换角色，向他们介绍 MongoDB 是做什么的、我们是谁、我们能够提供哪些帮助。”

最近我们在社区看到一些 IT 技术“老兵”回忆过往经历的帖子（比如这位 Sun 八号员工的故事），引发了很多讨论。有网友表示“对于开发者而言，计算机世界似乎正在变得无聊，从‘无’中创造出‘有’的兴奋感也越来越少”。

Mark 的观点恰恰与之相反。他认为，现在是成为一名开发者的最佳时机。直到最近，开发者这种职业仍被视为一种讲究战术的角色。换句话说，开发者通常不需要制定策略，相反，他们的任务是执行策略，将“企业”定义的数字体验展现出来，对 Mark 来说也是如此。但他认为这种情况正在发生变化。

随着数据库管理、编写代码等大量耗费时间的任务逐渐实现自动化操作，如今开发者可以将更多时间投入到更有价值的工作上，比如了解市场需求或识别有待解决的战略问题等。随着工作价值的提升，开发者的观点也越来越受到重视。因此，许多开发者的身份开始发生转变，由在公司埋头苦干的程序员，转变为具有高度战略眼光的远见者，能够借助数字经验帮助定义品牌。Mark 强调，疫情过后，开发者会比以往任何时候都更受欢迎。

“我们的未来将建立在应用程序基础之上，而开发者已经迅速从幕后走到了台前。”

Mark：是转做管理还是继续做个人贡献者（即普通员工），这是一个非常重要的选择。首先，你所服务的公司必须明确，无论你选择哪条职业发展路径，都会对你给予同等的重视。许多公司做不到这一点，还有一些公司做不到长期如此。每个管理岗都应该有对等的个人贡献者领导岗，并且应该享受同等薪酬。这样有助于人们在职业生涯早期作出正确选择。

我建议大家在做出选择时先正确审视自己。了解自己喜欢什么，不喜欢什么。我曾经见过有人这样做——根据自己对各项工作的喜爱程度及这份工作带来的价值等，在日历上为每项工作标记绿色、黄色或红色。通过这种方法，可以确定自己内心真正热爱的工作。一般来说，表现出色的人是那些在事业上有突出表现的人，例如说相较同龄人来说已经开始享受非线性薪酬激励等。大多数人只有做自己喜欢的事情时才能有出色的表现。热爱可以铸就成功，可以赋予他们直面逆境的力量。

如果你发现自己喜欢尝试解决公司内的各种问题，比如技术架构、产品上市、产品研发方向等问题，而且喜欢通过他人来完成工作，而不是事事亲力亲为，那么你可能比较适合做管理工作。我曾经读过这样一句话，“管理就是最崇高的职业。没有其他任何职业可以拥有如此多的手段帮助人们”。我认为的确如此，但这只适合于那些全心全意投入其中的人。如果你比较热衷于技术上的精益求精或在当前岗位发挥核心作用，那么可以试着在这方面做到更好——当然，前提条件是公司能够赋予你自主权及行业相当的职业待遇 / 薪酬。

Mark：这个问题很好。我从 CTO 和技术管理者两个方面分别来回答。

CTO 的类型很多。对于小公司来说，CTO 负责首个产品的开发，那么他们当然要参与开发工作。而对于大公司来说，CTO 主要负责对外活动，那么他们自然不用参与开发工作。我现在仍然会编写代码，但都是我和孩子们一起完成的项目以及我个人的项目。

至于技术管理者，也就是一线编码团队管理者，我认为在绝大多数情况下，他们应该参与代码开发工作。这些技术管理者必须能够使用工具、了解代码，并且拥有管理能力，只有这样才能把好事做到更好，把坏事变为好事。我强烈建议领导岗，至少是一线管理者甚至二线管理者，参与代码库的代码开发工作。当然，我完全理解，对于某些团队来说，管理岗并不一定非要开发代码。

Mark：说实话，我对数据库的兴趣一直非常浓厚。我认为数据库对于耐用性、正确性和可用性的承诺是计算机科学中最难实现的几个问题。所以，我的答案是数据库，就像我 30 年前第一次使用数据库时一样，我想对于那些对数据库感兴趣的人来说，我的答案可能并不足为奇。

现在，人们正在构建可运行于任何环境的平台，这些平台能够根据需要扩展和收缩，并且编程也越来越容易——即使在当下这个平台、架构和服务不断扩展的世界亦是如此。我满怀激情地加入 MongoDB，希望能够构建一种技术，让开发者、公司和客户在未来几年、甚至几十年里能够借助一个现代化平台实现联机事务处理（OLTP）、移动应用、搜索和分析能力，并可以根据需要随时进行扩展和缩放。这也是世界上最难的问题之一。

另外，我也着迷于芯片架构方面取得的进步。看到像 ARM 这样的现代架构能够突出重围，从各种拼凑在一起、满是漏洞的传统架构中夺得市场份额，令我非常激动。数据输入和输出速度已经得到数量级的提升，但芯片却未能保持同步的增长速度。我相信，凭借优秀的交叉编译器、测试框架和工具，我们一定可以帮助工程师在不影响工作效率的同时，在最先进的芯片设计上完成部署工作，甚至可以从中获得巨大收益。

架构师除了在技术上的专业需求之外，还要对业务逻辑、运营措施有所掌握。将于 7 月份在深圳举办的 ArchSummit 全球架构师峰会设置了「架构师能力模型」专题，这个专题会邀请各个领域的架构师来分享关于需求分析、问题定义、方案设计、研发实现、部署落地、持续运营的实践话题，点击阅读原文了解更多。

现在购票还可享受 9 折特惠价，单人立减 880 元，购票请扫码或咨询：18514549229（微信同电话)

点个在看少个 bug 👇