在技術洪流中看到我們的態度,第21期技術雷達正式發布!

  • 2019 年 11 月 26 日
  • 筆記

技術雷達是ThoughtWorks每半年發布一期的技術趨勢報告,它不僅是一份持續的技術成熟度評估,其產生還源於ThoughtWorks另一個更大宏大的使命—IT革命。我們一直深信,IT行業從定位、價值、實踐和技術都會發生巨大的變革。然而任何宏觀的變革,都會有一些微小的訊號,我們需要持續關注這些微小的改變,這也就是技術雷達的由來。

技術雷達自2010年創辦以來,已經走過10年、累計發布21期。它比那些我們能在市面上見到的其他技術行情和預測報告更加具體、更具可操作性,因為它不僅涉及到新技術大趨勢,更有細緻到類庫和工具的推薦和評論,因此更容易落地。

經過半年的追蹤與沉澱,ThoughtWorks TAB(ThoughtWorks技術諮詢委員會)根據我們在多個行業中的實踐案例,為技術者產出了第21期技術雷達,對百餘個技術條目進行分析,闡述它們目前的成熟度,並提供了相應的技術選型建議。

在主流雲服務提供商提供的核心功能日益趨同的當下,競爭焦點已經轉移到他們能夠提供的附加服務上,這就鼓勵了雲服務商以驚人的速度發布新產品。為在競爭中取得優勢,很多新服務還在存有瑕疵、功能尚不完整的階段,就被匆匆推向市場。過分關注速度以及產品擴張,常常導致這些由收購或倉促打造而來的服務缺陷頻出,文檔品質差,難於實現自動化,以及與服務商自己的其他服務不能完整集成。團隊在嘗試使用雲服務提供商承諾的功能卻經常遇到問題的時候,會感到挫敗。考慮到在選擇雲服務提供商時,通常都是由組織高層基於各個不同維度進行決策,我們建議實施團隊:不要假設你們的雲服務提供商的所有服務都能確保相同的品質,應該對關鍵功能進行測試。如果你們的產品上市時間能夠容納額外的運維開銷,可以考慮替代的開源解決方案,或者使用多雲策略。

保護軟體供應鏈

組織應該抵制冗長的人工檢測和需要審批的象牙塔治理規則。相反,自動化的依賴保護(依賴漂移適應度函數),安全性(安全策略即程式碼)和其他治理機制(運行成本納入架構適應度函數)可以保護軟體項目中重要但不緊急的部分。這個關於策略、合規性和治理即程式碼的主題在我們對話中多次出現。我們看到自動化不斷提升的軟體開發生態系統的自然演化:與自動測試、持續交付和基礎設施即程式碼的持續集成,以及如今的自動化治理。雲成本、依賴管理、架構結構等以往人工流程的自動化呈現出一種自然演進的態勢;我們正在學習如何讓軟體交付中的所有重要方面自動化。

打開機器學習的黑匣子

通過使用模式匹配、反向傳播和其他眾所周知的技術,機器學習通常貌似能解決人類所無法解決的問題。然而,儘管這些技術功能強大,但許多模型本質上令人費解。這意味著機器學習所計算的結果,無法用邏輯推理來解釋。所以,當需要了解決定是如何做出,或存在將偏見、抽樣、演算法或其他偏差引入模型的風險時,人們就會一籌莫展。現在我們看到,諸如假設分析之類的工具,以及道德偏差測試這樣的技術正在湧現出來。這些工具和技術可以幫助我們發現模型的局限性,並預測模型的輸出結果。儘管這些在可解釋性方面的改進,是朝著正確方向邁出的一步,但理解深度神經網路,仍然是一個遙不可及的目標。因此,在選擇機器學習模型時,數據科學家開始將可解釋性視為第一要務

軟體開發是一項團隊運動

技術雷達誕生之初,我們就提醒不要使用那些會分隔開發團隊、阻礙回饋及協作的工具和技術。通常,當新的專業人才參與項目後,為避免陷入「常規」開發的混亂局面,從業者、供應商和工具會要求某一些開發工作必須在隔離的環境中完成。我們反對這種觀念,也在不斷尋求新的方法使軟體開發重回團隊協作。在構建諸如軟體之類的複雜工程時,回饋是至關重要的。隨著項目不斷提升對專業人才的需求,我們努力讓他們融入常規的團隊協作和回饋互動中。我們特別不提倡「10倍工程師」的理念,更喜歡專註於創建和賦能「10倍團隊」。我們已經看到這在如何將設計、數據科學和安全融入跨功能團隊,並獲得成熟的自動化支援方面發揮了作用。下個階段應致力於引入更多治理方法和合規行為。

象限亮點搶先看

技術

10x engineers

在過去的幾個月中,10倍工程師一詞受到了密切的關注。一個廣泛傳播的推文討論在實質上建議公司應原諒反社會和破壞性的行為,以留住被認為個人產出巨大的工程師。幸運的是,許多人在社交媒體上都嘲笑了這個概念,但是「明星開發者」的刻板印象仍然普遍存在。根據我們的經驗,偉大的工程師不是因為個人產出而是因為能在優秀的團隊中合作而誕生。打造一支混合不同經驗和背景,但成員才華橫溢的團隊,並為團隊合作、學習和持續改進提供良好的助力,這會是更行之有效的方式。這些10倍團隊行動起來更快,彈性也更強,——而無需屈從錯誤的行為。

Zhong Tai

近年來,中台一直是中國IT界的流行語,但它尚未在西方國家流行起來。中台的核心是提供封裝業務模型的方法。它旨在幫助新型的小型企業提供一流的服務,而無需傳統企業基礎架構的成本,並使現有組織能夠以驚人的速度將創新服務推向市場。中台戰略最初是由阿里巴巴提出的,並很快被許多中國的互聯網公司所採用,因為它們的商業模式是數字原生的,可以複製到新的市場和領域。如今,越來越多的中國公司將中台作為數字化轉型的槓桿。

Continuous delivery for machine learning (CD4ML)

隨著基於ML的應用程式的日益普及以及構建它們所涉及的技術複雜性,我們的團隊嚴重依賴於機器學習的持續交付(CD4ML),以安全快速且可持續的方式交付此類應用程式。CD4ML是將CD原理和實踐引入ML應用程式的學科。它消除了從訓練模型到部署生產環境的長周期。在構建和部署模型的端到端過程中,CD4ML消除了不同團隊、數據工程師、數據科學家和ML工程師之間的手動傳遞。使用CD4ML,我們的團隊成功地實現了基於ML的應用程式所有組件的自動化版本管理,測試和部署,包括數據,模型和程式碼。

Ethical bias testing

在過去的一年,我們已經看到人們對機器學習尤其是深度神經網路的興趣正在發生變化。到目前為止,這些模型的卓越功能推動了工具和技術上令人興奮的發展。雖然目前,人們越來越擔心這些模型可能會造成意外傷害。例如,一個模型可以經過訓練,通過簡單地排除弱勢申請人,而做出有利可圖的信用決策。幸運的是,我們看到人們對道德偏見測試的興趣與日俱增,這將有助於發現潛在的有害決策。一些工具,例如lime, AI Fairness 360 或者 What-if,可以幫助我們發現一些訓練數據和可視化工具中未被充分代表的群體而導致的不準確性。可視化工具中,Google FacetsFacets Dive可以用來發現大量訓練數據中的子組。但是,這是一個正在發展的領域,我們期待隨著時間的推移,出現針對道德偏見測試的標準和實踐。

平台

Apollo Auto

正如 Apollo Auto 所展示的那樣,曾經只有科技巨頭才能獨享的自動駕駛技術,現在已經變得不再高深莫測。百度旗下的 Apollo 項目的目標,是成為自動駕駛產業里的Android作業系統。Apollo 平台擁有諸如感知、模擬、規劃以及智慧控制相關的一系列組件,能夠讓汽車公司將他們的自動駕駛系統集成到汽車硬體中。雖然開發者社區剛剛起步,但是許多第三方廠商陸續加入並貢獻良多。我們的一個項目就是幫助客戶,使用基於 Apollo 的自動駕駛系統,完成自動駕駛執照的考試。Apollo 同時也提供演進式架構的方法,以逐步引入先進功能,讓我們能以敏捷和迭代的方式,集成更多的感測器和功能。

GraalVM

GraalVM 是一種由 Oracle 開發的通用虛擬機,用於運行基於 JVM 的語言,JavaScript,Python,Ruby 和 R 以及 C/C++ 等其他基於 LLVM 的語言編寫的應用程式。簡單地說,GraalVM 可以用作 JVM 和其他所支援的非 JVM 的語言的高性能虛擬機。但它也允許我們編寫多種語言的應用程式,而且對性能影響很小; 它的原生鏡像程式(當前僅可作為早期採用者的技術使用)讓我們可以提前將 Java 程式碼編譯成獨立的可執行文件,從而加快啟動速度並減少記憶體的使用。GraalVM 在 Java 社區引起了巨大的反響,並且許多 Java 框架(包括MicronautQuarkusHelidon)已經在利用它的技術了。

Oculus Quest

我們在雷達中對 AR / VR(增強現實/虛擬現實)技術關注了很長時間,但其僅僅在特定的平台及外接方案上展現了吸引力。Oculus Quest 打破了這個局面,成為首批面向大眾消費市場的無需智慧手機綁定或支援的VR一體機之一。該設備為潛在的 VR 應用的大量增長打開了大門,其需求將反過來推動市場朝著更積極創新的方向發展。我們很欣賞該設備為VR普及帶來的推動力,迫不及待地想看到即將到來的變化。

ONNX

目前,圍繞神經網路的相關工具和框架的生態系統正在迅速地發展。但是,這些框架和工具之間的互通性也成為一個挑戰。在機器學習領域,通常需要在一種工具中快速進行原型設計和訓練,然後將其部署到其他工具中進行推理。因為這些工具的內部格式並不兼容,為了使他們兼容,我們需要實現並維護很多麻煩的轉換器。開放神經網路交換格式 ONNX 的出現,就是為解決這一問題。在 ONNX 中,表示神經網路的圖形由標準規格的操作符和一系列表示訓練權重和神經網路模型的格式所組成,這些圖形可以在不同的工具間傳遞。這種一致的格式帶來了很多的可能性,其中之一就是 Model Zoo,它是一系列基於 ONNX 格式的預訓練模型的集合。

工具

Figma

交互和視覺設計的一大痛點是缺乏用於協作的工具, Figma 就是為此而生的。它不僅具有與 Sketch 和 Invision 等設計程式相同的功能,而且還支援與其他人實時協作,幫助多人一起探索新的想法。我們的團隊發現Figma非常有用,特別是它支援與簡化了遠程和分散式的設計工作。除了協作功能之外, Figma 還提供了有助於改善 DesignOps 流程的API。

Jib

構建容器化應用程式可能需要在開發環境和構建代理上進行複雜的配置。如果你要構建 Java 應用程式並使用 Docker,則可以考慮使用 Google 的 Jib。Jib 是同時支援 Maven 和 Gradle 的開源插件。Jib 插件使用構建配置中的資訊,將應用程式直接構建為 Docker 鏡像,而不需要 Dockerfile 或 Docker 守護程式。Jib 也針對鏡像分層進行了優化,可以提升後續構建的速度。

Twistlock

Twistlock 是提供構建時和運行時安全漏洞檢測和預防功能的商業產品,可以保護 VM 、容器調度程式和容器,以及應用程式依賴的各類註冊中心和存儲庫。Twistlock 幫助我們的團隊加快了受監管應用程式的開發,這些應用程式的基礎設施和架構需要遵循一定的規範,例如支付卡行業(PCI)標準和《健康保險可移植性和責任法案》(HIPAA)。我們的團隊很享受 Twistlock 帶來的開發人員體驗:能夠以程式碼形式管理資源,可以輕鬆地與其他常見可觀察性平台進行集成,以及根據行業共識最佳實踐來衡量基礎架構的,直接可用的基準測試。我們在例行的運行時掃描過程中,尤其是在有合規性要求的情況下,使用 Twistlock 對雲原生應用程式進行掃描。

in-toto

我們注意到,越來越多的地方,尤其是在受監管的行業,為了確保軟體的供應鏈安全會使用二進位驗證。當前主流的做法,或是構建一個訂製的二進位驗證系統,亦或是依賴於某個雲廠商提供的服務。我們高興地看到出現了開源的in-toto 項目。In-toto 是一個框架,能夠以密碼學的方式驗證軟體製品生產路徑上的每個組件和步驟。該項目可以與眾多廣泛使用的構建工具、容器審計工具和部署工具進行集成。由於軟體供應鏈工具是一個組織的安全設施中至關重要的部分,因此我們非常喜歡 in-toto。作為一個開源項目,它的行為是透明的,並且其自身的完整性和供應鏈也可以由社區進行驗證。至於它是否會贏得足夠多的用戶和貢獻者以在這個領域競爭,我們拭目以待。

語言&框架

Arrow

Arrow 是適用於 Kotlin 的函數式編程庫,是由兩個現有流行庫( kategoryfunKTionale )合併而成。雖然 Kotlin 為函數式編程提供了構建模組,但 Arrow 為應用程式開發人員準備了隨時可用的高級抽象包。它提供數據類型、類型類、作用(Effects)、Optics 和其他函數式編程模式,並且可以與流行庫相集成。我們對於 Arrow 最初的好印象如今已經在生產環境的應用構建中得到了印證。

Flutter

我們的一些團隊使用了 Flutter 並且很喜愛它。作為跨平台框架,它可以幫助我們用 Dart 語言編寫原生移動應用。藉助 Dart,Flutter 可以編譯成平台原生程式碼並直接和目標平台通訊,從而避免了橋接和上下文切換。Flutter 的熱重載(hot-reload)特性亦讓人驚嘆,它能在編寫程式碼時提供超快的視覺回饋,我們推薦你在項目中嘗試使用 Flutter。

Gatsby.js

Gatsby.js是一個用於編寫 JAMstack 架構風格網路應用的框架。應用的一部分在構建時生成並且以靜態站點的形式進行部署。剩餘的功能以漸進式網路應用的方式進行實現並運行在瀏覽器中。這些應用無需服務端程式碼即可運行。通常來說,漸進式網路應用會通過調用第三方API,或者現成的 SaaS 解決方案實現內容管理等功能。在 Gatsby.js 的例子中,所有的客戶端和構建程式碼都是用 React 編寫。框架包含了一些優化來讓程式運行得更快。它將程式碼與數據分離來最大程度地減少載入時間,並且通過在應用內跳轉時預先載入資源來提高性能。介面通過 GraphQL 進行調用並且通過一些插件來簡化和現有服務的集成。

SwiftUI

蘋果在其新的 SwiftUI 框架上邁出了一大步,該框架用於在 macOS 和 iOS 平台上實現用戶介面。我們很高興 SwiftUI 跨越了 Interface Builder 和 XCode 之間略顯混亂的關係,並採用了一致的、聲明性的和以程式碼為中心的方式。現在,你可以在 XCode 11 中並排查看程式碼和生成的可視化介面,從而獲得更好的開發人員體驗。SwiftUI 框架還從近年來主導 Web 開發的React.js 的世界中汲取了靈感,它利用視圖模型中的不可變值和非同步更新機制,構成了統一的反應式編程模型。這為開發人員提供了一個完全原生的替代品,以替代類似 React NativeFlutter 之類的反應式框架。儘管 SwiftUI 確實代表了Apple UI 開發的未來,但它是一個相當新的事物,還需要花費一些時間來打磨。我們期待改進的文檔,和一個可以為測試與其他工程化問題建立一套實踐的開發者社區。