作者 | Thoughtworks
技術雷達是 Thoughtworks 每半年釋出一次的技術趨勢報告，它持續追蹤有趣的技術是如何發展的，我們将其稱之為條目。技術雷達使用象限和環對其進行分類，不同象限代表不同種類的技術，而環則代表我們對其作出的成熟度評估。
經過半年的追蹤與沉澱，Thoughtworks TAB（Thoughtworks 技術咨詢委員會）根據我們在多個行業中的實踐案例，為技術者産出了第 25 期技術雷達。對百餘個技術條目進行分析，闡述它們目前的成熟度，并提供了相應的技術選型建議。
一、本期主題
離奇集市：開源軟體不斷變化的經濟學
Thoughtworks 一直以來都是開源軟體的粉絲。因為 Eric Raymond 發表的著名文章《大教堂與集市》，開源軟體普及開來，提高了開發者的能動性，并用衆包的形式修複錯誤，以及創新。然而，商業化的嘗試呈現出目前生态系統巨大的經濟複雜性。
例如，Elastic 為了要求從中獲利的雲服務提供商做出回饋，更改了許可證，這導緻 AWS 在 2021 年 9 月将 Elasticsearch 複刻為 OpenSearch。這表明商業開源軟體要守護競争的護城河有多麼困難（同樣的問題也适用于免費的閉源軟體，因為 Docker 一直在努力尋找合适的商業模式，我們目睹了一些公司在探索 Docker Desktop 的替代品）。
有時，權力動态會反過來：由于 Facebook 資助了開源軟體 Presto ，Presto 的貢獻者得以保留 IP（知識産權），并在他們離開公司後将其重新命名為 Trino，這實際上得益于 Facebook 的投資。大量關鍵基礎設施都不是由企業贊助，這會讓情況會變得更加混亂，通常隻有在發現關鍵安全漏洞時，這些企業才會注意到他們對無償勞動的依賴程度（就像最近發生的 Log4J 問題）。
在某些情況下，通過 GitHub 或 Patreon 資助業餘愛好者和維護者，可以提供足夠的動力來産生影響；但對其他人而言，它是在他們的日常工作之上，增加了額外的責任感，并會導緻倦怠。我們仍然是開源軟體的堅定支援者，但也認識到經濟學正變得越來越離奇，并且沒有簡單的解決方案來找到正确的平衡。
軟體供應鍊的創新
衆所周知的重大安全事故 —— Equifax 資料洩露、SolarWinds 攻擊、Log4J 遠端零日漏洞攻擊等等，都是由于軟體供應鍊的管理不善造成的。開發團隊現在意識到，可靠的工程實踐也包括項目依賴項的驗證和管理，是以本期技術雷達上出現了許多與之相關的條目。這些條目包括一些檢查清單和标準，如軟體工件供應鍊層級（SLSA）：一個由谷歌主推，旨在為供應鍊的正常威脅提供指導；以及 CycloneDX：一個由 OWASP 社群推動的另一套标準。我們還介紹了一些具體的工具，如 Syft，它能夠為容器鏡像生成軟體物料清單（SBOM）。
黑客越來越多地利用安全領域攻防不對稱的特點，并且結合日益複雜的黑客技術進行攻擊 —— 這意味着他們隻需要找到一個漏洞即可，而防禦者必須確定整個攻擊面的安全。在我們努力保持系統安全的過程中，改善供應鍊安全是我們應對措施中的關鍵部分。
為什麼開發者們總熱衷于在 React 中實作狀态管理？
蓬勃發展的架構似乎成為了技術雷達中一種常見的模式：一個基礎的架構變得流行起來，緊接大量工具的浮現建立出一個針對常見缺陷和改進的生态系統，最後以幾個流行工具的鞏固而結束。然而，React 的狀态管理似乎在抵制這種通用的趨勢。自從 Redux 釋出後，我們看到源源不斷的工具和架構以略微不同的方式來管理狀态，每一種都有不同的權衡取舍。
我們不知道原因，我們隻能推測：這是 JavaScript 生态系統似乎提倡的自然流失嗎？或者是 React 存在的一個有意思且看似易于修複的潛在缺陷，鼓勵着開發人員多做實驗嗎？還是文檔閱讀格式（浏覽器）與在它之上托管的應用程式所需要的互動性（和狀态）之間存在永遠無法比對的障礙？我們不知道原因，但是我們期待下一輪的嘗試，來解決這個看似永恒的問題。
對主資料編目永無止境的追求
從企業資料資産中挖掘更多價值的願望，驅動了我們目前所看到的在數字技術方面的大部分投資。這項工作的核心通常集中在發現并通路所有相關資料上。幾乎隻要企業在收集數字資料，它就一直在努力将其合理化并編目到一個單一的、自上而下的企業目錄。然而一次又一次，這一直覺上吸引人的概念與大型組織中固有的複雜性、備援性和模糊性的殘酷現實背道而馳。最近，我們注意到人們對企業資料編目重新産生了興趣，以及大量相關巧妙新工具的雷達條目提議，例如 Collibra 和 DataHub 。這些工具能夠對跨倉庫資料譜系和中繼資料提供一緻的、可發現的通路，但它們不斷擴充的功能集也延伸到了資料治理、品質管理、釋出等方面。
與這種趨勢相反，遠離自上而下的中心化資料管理，走向基于資料網格架構的聯合治理和資料發現的趨勢也在增長。這種方法對期望和标準進行集中設定，而資料管理則根據業務領域線來劃分，解決了企業資料的固有複雜性。面向領域的資料産品團隊控制并分享自己的中繼資料，包括可發現性、品質和其它資訊。此時，編目隻是一種為搜尋和浏覽而展示資訊的方式。生成的資料編目更加簡單且更易維護，進而減少了對功能豐富的編目和治理平台的需求。
二、部分象限亮點搶先看
SLSA（評估）
随着軟體複雜性的不斷增加，軟體依賴項的威脅路徑變得越來越難以守護。最近的 Log4J 漏洞表明了解這些依賴關系有多困難——許多沒有直接使用 Log4J 的公司在不知不覺中就變得脆弱，因其生态系統中的其他軟體依賴于 Log4J。軟體工件供應鍊層級，又稱 SLSA（讀作 “salsa”），是一個由聯盟組織策劃的，為組織機構提供防範供應鍊攻擊的指南集。該架構衍生于一個 Google 多年來一直使用的内部指南。值得稱贊的是，SLSA 并沒有承諾提供“銀彈”，即僅使用工具確定供應鍊安全的方法，而是提供了一個基于成熟度模型的具體威脅和實踐的清單。這威脅模型是很容易了解的，其中包含了真實世界發生的攻擊執行個體，并且要求文檔中也提供了指南，幫助組織基于日漸增強的穩健性水準為其行動措施排定優先級，以改善他們供應鍊的安全态勢。我們認為 SLSA 提供了适用的建議，并期待更多組織機構從中學習。
伺服器端驅動 UI（ 試驗）
當彙總新一期技術雷達的時候，我們時常被一種似曾相識的感覺所傾倒。随着開發架構的湧現，伺服器端驅動 UI 技術引發了一個熱議話題。這項技術允許移動端開發者利用更快的變更周期，而不違反應用商店關于重新驗證移動應用的任何政策。我們在之前的雷達中從賦能移動開發跨團隊擴充的角度介紹過這項技術。伺服器端驅動 UI 将渲染分離到移動應用程式的一個通用容器中，而每個視圖的結構和資料由伺服器提供。這意味着對于過去那些需要經曆一次應用商店釋出之旅的修改，現在隻需要簡單改變伺服器發送的響應資料即可實作。需要說明的是，我們不推薦對所有 UI 開發都使用這種方式。我們的确陷入過一些可怕的過度配置的困境，但是在 AirBnB 和 Lyft 這樣巨頭的背書下，我們懷疑不隻是我們 Thoughtworks 厭倦了一切交給用戶端。這一領域值得關注。
tfsec（采納）
對于那些我們正在使用 Terraform 的項目來說，在需要檢測潛在安全風險時，tfsec 已經迅速成為預設的靜态分析工具。它很容易被內建到 CI 流水線，而且擁有一個持續增長的檢查庫，可以用來檢查所有主要的雲供應商和諸如 Kunernetes 的平台。鑒于它的易用性，我們相信對任何 Terraform 項目而言，tfsec 都會是一個非常好的補充。
雲服務的碳足迹（試驗）
Cloud Carbon Footprint (CCF) 是一款通過雲 API 來檢視 AWS、GCP、Azure 雲平台上碳排放的可視化工具。Thoughtworks 的團隊已經成功使用這個工具 與多個組織合作，其中包括能源科技公司、零售商、數字服務的供應商和使用人工智能的公司。雲平台提供商意識到，幫助客戶了解在使用雲服務時産生的碳排放的影響是很重要的。是以他們開始自主建構類似的功能。因為 CCF 是獨立于雲架構的，它允許使用者在一個位置檢視多個不同雲服務商的能源使用和碳排放情況，同時将碳足迹轉化為對現實世界的影響，比如排放量相當于多少次航班， 或者多少棵樹。在最近的釋出中，CCF 已經開始包含針對 Google 雲和 AWS 雲上可能的節能與減少二氧化碳排放的優化建議，以及支援更多類型的雲執行個體，比如 GPU。考慮到現在這個工具已經備受關注和持續增加新功能， 我們對未來把它挪入試驗狀态充滿信心。
eBPF（試驗）
近些年來，Linux 核心已經包括了擴充的伯克利資料包過濾器（eBPF），一個提供了将過濾器附加到特定套接字能力的虛拟機。但是，eBPF 遠遠超出了包過濾的範圍，它允許在核心的不同點位上觸發自定義腳本，而且開銷非常小。雖然這項技術并不新鮮，但随着越來越多的微服務通過容器編排來部署，eBPF 逐漸自成一體。Kubernetes 和服務網格技術（如 Istio ）被普遍使用，它們采用“邊車” （sidecars） 來實作控制功能。有了諸如 Bumblebee 這樣使 eBPF 程式的建構、運作和釋出變得更加容易的新工具， eBPF 可以被看作是傳統邊車的替代品。Cilium 的維護者甚至宣布了邊車的消亡。基于 eBPF 的方法減少了一些由邊車帶來的性能和運維上的開銷，但它不支援如本地終結 SSL 會話這樣的常見功能。
Cloudflare Pages（評估）
當 Cloudflare Workers 釋出的時候，我們着重介紹它是一個面向邊緣計算的早期函數即服務（FaaS）方案，實作方案十分有趣。去年（2021 年）四月釋出的 Cloudflare Pages 并沒有特别引人注目，因為 Pages 隻是衆多基于 Git 的網站托管解決方案中的一個。雖然 Cloudflare Pages 的确有一個大多數替代方案不具備的有用功能——持續預覽。不過，現在 Cloudflare 已經将 Workers 和 Pages 更緊密地內建了起來，建立了一個運作在 CDN 上的、完全內建的 JAMstack 解決方案。鍵值存儲和高度一緻的協調原語讓新版 Cloudflare Pages 更具吸引力。
Testcontainers（采納）
根據長期使用 Testcontainers 的經驗，我們認為它是建立可靠的環境來運作自動化測試的預設選項。Testcontainers 是一個擁有多種語言版本 的庫，并且 docker 化了常見的測試依賴——包括了不同種類的資料庫，隊列技術，雲服務和 UI 測試依賴（例如 web 浏覽器），還具有按需運作自定義 Dockerfile 的能力。它與類似 JUnit 的測試架構相容，而且足夠靈活，可以讓使用者管理容器的生命周期和進階網絡，并迅速建立一個內建測試環境。
Zig（評估）
Zig 是一門新的語言，它與 C 語言共享了許多屬性，但是具有更強的類型，更簡便的記憶體配置設定，以及對命名空間和衆多其他特性的支援。然而它的文法，比起 C 更容易讓人想到 JavaScript，這點會引起一些人的反對。Zig 的目标是為大家提供一種非常簡單的語言，可以直接編譯以減少副作用，并且程式執行是可預測和易于追蹤的。Zig 還提供了 LLVM 交叉編譯功能的簡化接口。我們的一些開發同僚發現這一特性非常重要，以至于他們盡管沒有使用 Zig 程式設計，但是仍然把它當做一個交叉編譯器使用。Zig 是一種新穎的語言，對于正在考慮或者已經使用 C 語言的應用程式，以及需要顯式記憶體操作的底層系統應用程式，值得一試。