技術雷達是ThoughtWorks每半年發佈一期的技術趨勢報告，它不僅是一份持續的技術成熟度評估，其產生還源於ThoughtWorks另一個更大宏大的使命—IT革命。我們一直深信，IT行業從定位、價值、實踐和技術都會發生巨大的變革。然而任何宏觀的變革，都會有一些微小的信號，我們需要持續關注這些微小的改變，這也就是技術雷達的由來。
技術雷達自2010年創辦以來，已經走過10年、累計發佈22期。它比那些我們能在市面上見到的其他技術行情和預測報告更加具體、更具可操作性，因爲它不僅涉及到新技術大趨勢，更有細緻到類庫和工具的推薦和評論，因此更容易落地。
經過半年的追蹤與沉澱，ThoughtWorks TAB（ThoughtWorks技術諮詢委員會）根據我們在多個行業中的實踐案例，爲技術者產出了第22期技術雷達，對百餘個技術條目進行分析，闡述它們目前的成熟度，並提供了相應的技術選型建議。
本期四大主題
Zoom 裏的大象
“需求是發明之母”——諺語
隨着相關技術緩慢成熟，許多公司已經實踐了遠程辦公的想法。但是非常突然地，一場全球瘟疫大流行迫使全世界的公司迅速從根本上改變了他們的工作方式，以此來保護一些生產力。正如很多人已經注意到，“居家辦公”與“在疫情期間被迫居家辦公”是截然不同的，並且我們認爲在這種新的背景下要實現完全的生產力，前方還會有一段路要走。
所以伴隨這一期雷達，你還會擁有一期討論我們以遠程優先的方式製作雷達的體驗的播客、一份關於遠程優先生產力的建議的報告、一場涉及危機中的技術策略的網絡研討會，還有一些指向其他 ThoughtWorks 材料的鏈接，包括我們的 Remote Working Playbook 。我們希望這些材料與網絡上其他材料一道，幫助組織在這片未知水域中安全航行。
X 也是軟件
我們經常鼓勵軟件交付生態系統中的其他團隊，採用敏捷軟件開發團隊所開拓的、有益的工程實踐。但我們也發現這些工程實踐在部分領域的應用進展緩慢，所以我們經常討論這個主題。在本期技術雷達中，我們決定再次強調基礎設施即代碼以及流水線即代碼，並討論了基礎設施配置、機器學習流水線等相關的領域。我們發現，通常負責這些領域的團隊並不採用軟件設計原則、自動化、持續集成及測試等久經考驗的工程實踐。我們理解有很多因素都會阻礙部分工程實踐的快速發展，如軟件（必然和偶然的）複雜性、缺乏知識、政治原因、缺乏合適工具等。但是，組織可以從敏捷軟件交付實踐中獲得的好處也是顯而易見的，所以值得爲此付出一些努力。
數據視角的成熟和擴展
在本期技術雷達中，關於數據成熟度的主題橫跨了多個條目和象限，特別是圍繞分析數據和機器學習的技術和工具。我們注意到自然語言處理（NLP）領域中的許多持續創新；我們也歡迎機器學習的全生命週期工具套件的出現和持續發展，將經久不衰的工程實踐與迭代中表現良好的工具組合結合起來，表明"機器學習也是軟件"。最後，對於像微服務這樣的分佈式架構，我們看到了對數據網格的極大興趣，這是一種能在分佈式系統中有效地服務和使用大規模分析數據的方法。隨着業界更加用心地思考數據在現代系統中的工作方式，我們也爲這個領域的總體方向和開放的視角感到歡欣鼓舞，並期待在不久的將來能看到振奮人心的創新。
Kubernetes生態系統的寒武紀爆發
Kubernetes 市場主導地位的持續鞏固，必然促成其生態系統的蓬勃發展。我們在工具、平臺和技術象限中，圍繞 Kubernetes 討論了若干雷達條目。這表明該主題已無處不在。例如，Lens 和 k9s 簡化了集羣管理，kind 有助於本地測試，Gloo 則是一種可選的 API 網關。Hydra 是爲在 Kubernetes 上運行而優化了的 OAuth 服務器，而 Argo CD 則使用 Kuberenetes 的原生預期狀態管理功能，來實現一個持續交付服務器。這些發展表明，圍繞Kubernetes 完全可以建立一個支持性的生態系統。Kubernetes 雖然提供了關鍵功能，但其抽象程度對於大多數用戶而言，不是太細碎，就是太高深。爲解決這些複雜性，相關工具就應運而生，以簡化 Kubernetes 的配置和使用，或提供 Kubernetes 核心功能中所缺失的特性。隨着 Kubernetes 繼續佔據主導地位，我們看到其繁榮的生態系統在不斷髮展和壯大，並能揚長避短。這個生態系統正日趨成熟，我們希望它會朝着一組新的更高層次的抽象去演化，以發揮 Kubernetes 的優勢，而不是給出衆多選擇，讓人莫衷一是。
象限亮點搶先看
將產品管理思維應用於內部平臺
越來越多的公司正在構建內部平臺，藉此快速有效地推出新型數字化解決方案。成功實施這一戰略的企業正將產品管理思維應用於內部平臺。這意味着與內部消費者（開發團隊）建立共情，並在設計上彼此協作。平臺的產品經理要建立路線圖，確保平臺爲業務交付價值，爲開發者改善體驗。不幸的是，我們也見到了一些不太成功的方式，團隊在未經驗證的假設、沒有內部客戶的情況下，打造出的平臺猶如空中樓閣。這些平臺儘管採用了激進的內部策略，但往往無法充分利用，還耗盡了組織的交付能力。和其他產品一樣，好的產品管理就是爲消費者創造喜愛的產品。
零信任架構
隨着資產（數據、功能、基礎架構和用戶）跨越安全邊界（本地主機，多雲提供商以及各種SaaS供應商），組織的技術版圖正在變得越來越複雜。這就要求企業安全計劃和系統架構進行範式轉變：從基於信任區和網絡配置的靜態、緩慢改變的安全策略，轉變爲基於臨時訪問權限的動態、細粒度的安全策略。
零信任架構(Zero trust architecture, ZTA)是組織針對其所有資產（設備、基礎設施、服務、數據及用戶）實施零信任安全原則的策略和流程，以及對最佳實踐的踐行（包括不論網絡位置確保所有訪問和通信的安全、強制基於最小權限原則並儘可能細粒度控制的策略即代碼、持續監控和自動緩解威脅等）。技術雷達介紹了很多賦能技術，例如安全策略即代碼，端點安全邊車 和 BeyondCorp。如果準備進一步瞭解ZTA，請參閱 NIST ZTA 和 Google 在 BeyondProd 上發表的文章，以瞭解更多關於原則、賦能技術組件及遷移模式的信息。
預檢構建
儘管相比 Gitflow 來說，我們強烈推薦 CI，但我們知道直接向主幹提交然後在 master 分支上跑 CI，在團隊過大的時候是低效的。構建會變慢或不穩定，也可能團隊會缺乏在本地運行完整測試集的紀律。在這種情況下，一次紅色的構建可以阻塞多名或多對開發者的工作。許多團隊通常依賴功能分支來繞過這些問題，而不是解決潛在的根本原因——構建緩慢、不能本地運行測試或迫使許多人在同一位置工作的單體架構。我們不鼓勵功能分支，因爲它可能需要巨大的努力來解決合併衝突，並且還可能在解決衝突的過程中拉長了反饋週期和引入缺陷。取而代之的是，我們提議使用預檢構建作爲替代方案：它是基於 Pull Request 的構建，針對只在流水線運行期間存在的爲每個commit建立的微型分支。爲了自動化這一工作流，我們已經見到了類似 Bors 這樣的機器人程序，它將合併 master 分支和刪除迷你分支（當構建成功時）的工作自動化。我們正在評估這個流程，你也應該試試看，但請不要用它去解決錯誤的問題，因爲這樣的話可能會帶來分支濫用，導致弊大於利。
用於業務分析的日誌聚合
幾年前，出現了新一代的日誌聚合平臺，該平臺能夠存儲和搜索大量的日誌數據，用來發掘運營數據中的趨勢和洞見。這種工具有很多，Splunk是其中最著名的。由於這些平臺可在整個應用程序範圍內提供廣泛的運營和安全可見性，因此管理員和開發人員越來越依賴於它們。當干係人發現可以使用“日誌聚合進行業務分析”時，他們便開始樂於此道。但是，業務需求可能會很快超越這些工具的靈活性和可用性。旨在提供技術可觀察性的日誌通常很難對用戶有深刻的理解。我們更喜歡使用專門爲用戶分析而設計的工具和指標，或者採用更具事件驅動性的可觀察性方法，其中收集、存儲業務和運營事件的方式可以用更多專用工具來重現和處理。
.NET Core
雖然.NET Core之前已進入雷達的採納環，表明它已成爲我們 .NET 項目的默認平臺，但我們覺得有必要再次關注一下 .NET Core。隨着去年 .NET Core 3.x 的發佈，.NET Framework 的大部分特性，現在都已移植到 .NET Core 中。微軟在 .NET Framework 最新一次發佈中，強調.NET Core 是 .NET 的未來。微軟已經做了大量工作，來使 .NET Core 達到容器友好。我們大多數基於 .NET Core 的項目，都是針對Linux的，並通常以容器形式進行部署。即將發佈的 .NET 5，看起來很有前途，我們對此充滿期待。
eBPF
幾年來，Linux 內核已經內置eBPF（extended Berkeley Packet Filter）虛擬機，並提供將eBPF 過濾器掛載到特定套接字（socket）的功能。但是 eBPF 能做的遠不止包過濾。它允許以很少的開銷，在內核中不同的地方，觸發自定義腳本。儘管這不是新技術，但隨着容器化部署微服務的流行，其價值逐漸顯露出來。在這些系統中，服務到服務的通信可能很複雜，因此很難將延遲或性能問題與 API 調用關聯起來。現在一些工具會內置eBPF腳本，用於收集和可視化數據包流量，或報告 CPU 利用率。隨着 Kubernetes 的興起， 出現了基於 eBPF 腳本的新一代安全實施和檢測工具，以降低大規模微服務部署的複雜性。
Cosmos
自從我們在技術雷達中，對區塊鏈這一領域作出初始評估以來，該領域技術的性能有了極大的提升。然而，目前仍然沒有哪個區塊鏈平臺能夠達到“互聯網級別”的吞吐量。各種區塊鏈平臺相繼發展，產生了不少新的數據和價值孤島。這使得區塊鏈社區的關鍵主題一直是跨鏈技術。區塊鏈的未來，可能是由若干獨立且並行的區塊鏈而組成的網絡。這也是 Cosmos 的願景。Cosmos 發佈了 Tendermint 和 CosmosSDK，以使開發人員可以定製獨立的區塊鏈。這些並行的區塊鏈，可以通過 IBC（Inter-Blockchain Communication，區塊鏈間通信協議） 和 Peg Zone 來交換價值。對於 CosmosSDK ，我們的團隊擁有豐富的經驗。而 IBC 協議正在日趨完善。這種架構可以解決區塊鏈的互操作性和可伸縮性的問題。
Node氾濫
技術都有被濫用的趨勢，尤其是廣爲流行的技術。比如現在所見到的“Node氾濫”現象，就是一種隨意或誤用 Node.js 的趨勢。其中有兩點很突出。首先，我們經常聽到這樣的說法——應該使用Node，這樣只用一種編程語言，就能完成前後端的所有代碼。對此，我們還是堅持認爲多語言編程是一種更好的方法，儘管我們也將JavaScript作爲一等語言。其次，我們經常聽到團隊將性能作爲選擇 Node.js 的理由。這種觀點已經被大量比較合理的基準數據所否定，但其來源還是有歷史原因的。當初， Node.js 變得流行時，還是首個使用非阻塞編程模型的主流框架。該模型讓 Node.js 非常適合IO密集型任務（我們在2012年的Node.js文章中提到了這一點）。由於單線程的特點，Node.js 從來就不是計算密集型任務的理想選擇。而現在，其他平臺已經擁有功能強大的非阻塞框架（其中一些已經配備既優雅又現代的 API ）。所以性能已不再是選擇 Node.js 的理由。
Figma
不論是對設計師，還是多角色團隊而言，Figma 都已被證明是協作設計的首選工具。它允許開發人員和其他角色通過瀏覽器查看和評論設計，而無需使用桌面版本。和它的競爭對手（如Invision 或 Sketch）相比，Figma 將版本控制、協作設計和設計分享這些功能都集中到一個工具上，這使得我們的團隊更容易一起想出新點子。我們的團隊發現 Figma 十分有用，特別是在開啓和促進遠程分佈式設計工作方面。除了實時設計和協作功能外，Figma 還提供了一個 API 以幫助改善 DesignOps 流程 。
用於機器學習的實驗跟蹤工具
機器學習的日常工作通常可以歸結爲一系列的實驗，包括選擇建模方法和網絡拓撲，訓練數據以及優化調整模型。數據科學家必須利用經驗和直覺來做出一些假設，然後去評估這些假設對模型的整體性能的影響。隨着這種實踐的成熟，我們的團隊發現對“用於機器學習的實驗跟蹤工具”的需求日益增長。這些工具可以用於幫助研究人員跟蹤實驗， 從而使這些實驗變得更加的有條不紊。儘管這個領域還沒有出現明確的贏家，但是已經出現了MLflow 這類的工具以及諸如Comet和Neptune這樣的平臺，它們使得整個機器學習的工作流程變得更加的嚴謹和可重複。
Gloo
隨着 Kubernetes 和 service mesh 的日益普及，API 網關在雲原生分佈式系統中一直面臨着生存危機。畢竟，許多 API 網關的功能，如流量控制，安全性，路由和可觀察性等，現在都是由集羣的入口控制器和網格網關提供。Gloo 是一個支持這種變化的輕量級API網關，它使用 Envoy 作爲其網關技術，同時爲外部用戶和應用程序提供附加價值，如 API 的內聚視圖等。Gloo 還提供了一套管理界面用於控制 Envoy 網關，並運行和集成了多個服務網格的實現，如 Linkerd，Istio 和 AWS App Mesh。儘管它的開源版本已經提供了 API 網關的基本功能，但它的企業版有一組更成熟的安全控件，如 API 密鑰管理， OPA集成等。Gloo 是一個很有前途的輕量級 API 網關。它很好地適應了雲原生技術和架構的生態系統，同時避免了在 API 網關中引入業務邏輯以迎合最終用戶的陷阱。
Snowpack
Snowpack 是 JavaScript 構建工具領域中的一個有趣的新成員。與其他解決方案相比，Snowpack 的關鍵的改進是可以使用 React.js，Vue.js 和 Angular 等現代框架來構建應用程序，而無需打包器。由於省去了打包的環節，對代碼的任何修改都幾乎可以立即顯示在瀏覽器上，因此開發過程中的反饋週期得到了極大的改善。爲了達到這個神奇的效果，Snowpack 將 node_modules 中的依賴轉換爲單個的 JavaScript 文件，並將其放置於一個新的 web_modules 目錄中，從這個目錄中可以將它們作爲 ECMAScript 模塊（ESM）導入。對於 IE11 和其他不支持 ESM 的瀏覽器，它也支持一種變通方法。遺憾的是，目前還沒有任何瀏覽器可以從 JavaScript 中導入 CSS，因此使用 CSS 模塊 並不簡單。
Karate
基於認爲測試是唯一真正重要的 API 規範的經驗，我們一直在尋找對測試有幫助的新工具。Karate 是一種 API 測試框架，其獨特之處在於它不依賴通用編程語言，而直接使用基於 Gherkin 的語法編寫測試。Karate 使用一種領域特定語言，來描述基於HTTP的API測試。我們的團隊喜歡 Karate 爲 API 規範帶來的易讀性，並建議將其應用於測試金字塔的較高層次，而非過量應用在細節的斷言中。
Koin
隨着 Kotlin 被越來越多地用於移動和服務端開發，其相關生態系統也在不斷髮展。Koin 是一個Kotlin框架，用於處理軟件開發中的常規問題之一：依賴注入。儘管有多種 Kotlin 依賴注入框架可供選擇，我們的團隊更喜歡 Koin 的簡單性。Koin 避免使用註解，而是通過構造函數或模仿 Kotlin 的延遲初始化，從而僅在需要時才注入對象。這與 Android 基於靜態編譯的 Dagger 注入框架形成鮮明對比。我們的開發人員喜歡此框架的輕量級本質及其內置的可測試性。
ERNIE
在上一期技術雷達中，我們加入了BERT—— NLP（Natural Language Processing，自然語言處理） 領域中的一個關鍵里程碑。去年，百度發佈了 ERNIE 2.0（Enhanced Representation through kNowledge IntEgration），它在 7 個 GLUE(General Language Understanding Evaluation) 語言理解任務和全部 9 箇中文 NLP 任務上的表現均優於 BERT。和 BERT 一樣，ERNIE 也提供了無監督預訓練語言模型。它可以通過添加輸出層的方法來進行微調，以創建多種 NLP 任務的當前最優模型。ERNIE 與傳統預訓練方法不同之處在於，它是一個連續的預訓練框架。它可以不斷地引入各種各樣的預訓練任務，以幫助模型有效地學習語言表達，而不是僅使用少量的預訓練目標進行訓練。我們對 NLP 的進步感到非常興奮，並期待在我們的項目中嘗試。
Tailwind CSS
CSS工具和框架提供了預先設計的組件，幫助開發者快速實現想要的頁面效果。但是隨着開發的進行，它們變得難以定製。Tailwind CSS 提供了一種有趣的方法。爲了便於定製，它僅提供了較低層次的CSS樣式類來構建模塊，且沒有自帶任何多餘的複雜樣式。較低層次CSS樣式類廣泛的覆蓋，使開發者不需要編寫任何新的樣式類或CSS樣式。從長遠來看，這將產出更易於維護的代碼。這樣來看 Tailwind CSS 在可重用性和自定義創建可視化組件之間，提供了適當的平衡。
以上是我們在最新一卷技術雷達中隨機摘取的幾個Blip，欲獲取整版技術雷達，請點擊左這裏進行下載！
更多精彩洞見，請關注微信公衆號：ThoughtWorks洞見