「藉助 MongoDB，你可以很自然地用自己的語言編程，無需再藉助極為複雜的 SQL 轉換層。我認為，這是過去十年來資料庫技術領域規模最大、最重要的一次轉變。」
自誕生以來，MongoDB 憑藉靈活的文檔模型、可擴展性和高可用性等優勢獲得了無數開發者的支持，並一直在DB-Engines排行中占據著所有資料庫前五、文檔型資料庫第一的位置。
作為關係型資料庫強有力的 Challenger ，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 Porter：從 Tech Geek 到技術管理者
InfoQ：大部分開發者/工程師工作幾年之後，都會面臨是否轉做技術管理的選擇。很多人會對此感到迷茫，他們的問題可能包括「要不要轉技術管理」「我是否適合做技術管理」或「如果不做管理，繼續在一線做開發有前途嗎」等等。開發者如何做出正確的選擇，不同的選擇分別有哪些方面需要注意，能否基於您的經驗（包括您自身的經驗和您所管理的團隊成員的經驗），給大家一些建議？
Mark：是轉做管理還是繼續做個人貢獻者（即普通員工），這是一個非常重要的選擇。首先，你所服務的公司必須明確，無論你選擇哪條職業發展路徑，都會對你給予同等的重視。許多公司做不到這一點，還有一些公司做不到長期如此。每個管理崗都應該有對等的個人貢獻者領導崗，並且應該享受同等薪酬。這樣有助於人們在職業生涯早期作出正確選擇。
我建議大家在做出選擇時先正確審視自己。了解自己喜歡什麼，不喜歡什麼。我曾經見過有人這樣做——根據自己對各項工作的喜愛程度及這份工作帶來的價值等，在日曆上為每項工作標記綠色、黃色或紅色。通過這種方法，可以確定自己內心真正熱愛的工作。一般來說，表現出色的人是那些在事業上有突出表現的人，例如說相較同齡人來說已經開始享受非線性薪酬激勵等。大多數人只有做自己喜歡的事情時才能有出色的表現。熱愛可以鑄就成功，可以賦予他們直面逆境的力量。
如果你發現自己喜歡嘗試解決公司內的各種問題，比如技術架構、產品上市、產品研發方向等問題，而且喜歡通過他人來完成工作，而不是事事親力親為，那麼你可能比較適合做管理工作。我曾經讀過這樣一句話，「管理就是最崇高的職業。沒有其他任何職業可以擁有如此多的手段幫助人們」。我認為的確如此，但這隻適合於那些全心全意投入其中的人。如果你比較熱衷於技術上的精益求精或在當前崗位發揮核心作用，那麼可以試著在這方面做到更好——當然，前提條件是公司能夠賦予你自主權及行業相當的職業待遇/薪酬。
InfoQ：業內關於 CTO、技術管理者是否仍應該積極開發代碼存在不少爭議。您對此有何看法？您認為 CTO 還有必要參與一線代碼開發工作嗎？
Mark：這個問題很好。我從 CTO 和技術管理者兩個方面分別來回答。
CTO 的類型很多。對於小公司來說，CTO 負責首個產品的開發，那麼他們當然要參與開發工作。而對於大公司來說，CTO 主要負責對外活動，那麼他們自然不用參與開發工作。我現在仍然會編寫代碼，但都是我和孩子們一起完成的項目以及我個人的項目。
至於技術管理者，也就是一線編碼團隊管理者，我認為在絕大多數情況下，他們應該參與代碼開發工作。這些技術管理者必須能夠使用工具、了解代碼，並且擁有管理能力，只有這樣才能把好事做到更好，把壞事變為好事。我強烈建議領導崗，至少是一線管理者甚至二線管理者，參與代碼庫的代碼開發工作。當然，我完全理解，對於某些團隊來說，管理崗並不一定非要開發代碼。
InfoQ：作為技術管理者，您一直以來是如何培養和保持自己對技術的前瞻性的？
Mark：說實話，我對資料庫的興趣一直非常濃厚。我認為資料庫對於耐用性、正確性和可用性的承諾是計算機科學中最難實現的幾個問題。所以，我的答案是資料庫，就像我 30 年前第一次使用資料庫時一樣，我想對於那些對資料庫感興趣的人來說，我的答案可能並不足為奇。
現在，人們正在構建可運行於任何環境的平台，這些平台能夠根據需要擴展和收縮，並且編程也越來越容易——即使在當下這個平台、架構和服務不斷擴展的世界亦是如此。我滿懷激情地加入 MongoDB，希望能夠構建一種技術，讓開發者、公司和客戶在未來幾年、甚至幾十年裡能夠藉助一個現代化平台實現聯機事務處理（OLTP）、移動應用、搜索和分析能力，並可以根據需要隨時進行擴展和縮放。這也是世界上最難的問題之一。
另外，我也著迷於晶片架構方面取得的進步。看到像 ARM 這樣的現代架構能夠突出重圍，從各種拼湊在一起、滿是漏洞的傳統架構中奪得市場份額，令我非常激動。數據輸入和輸出速度已經得到數量級的提升，但晶片卻未能保持同步的增長速度。我相信，憑藉優秀的交叉編譯器、測試框架和工具，我們一定可以幫助工程師在不影響工作效率的同時，在最先進的晶片設計上完成部署工作，甚至可以從中獲得巨大收益。
