第二十期技術雷達正式發佈——給你有態度的技術解析

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

技術雷達自2010年創辦以來，已經走過十年、累計發佈二十期。它比那些咱們能在市面上見到的其餘技術行情和預測報告更加具體、更具可操做性，由於它不只涉及到新技術大趨勢，更有細緻到類庫和工具的推薦和評論，所以更容易落地。通過半年的追蹤與沉澱，ThoughtWorks TAB（ThoughtWorks技術諮詢委員會）根據咱們在多個行業中的實踐案例，爲技術者產出了第20期技術雷達，對百餘個技術條目進行分析，闡述它們目前的成熟度，並提供了相應的技術選型建議。

本期主題

突飛猛進的數據形態

十年前，數據幾乎等同於關係數據庫。現在，數據則可能呈現出各類形態，包括NoSQL、時間序列、像CockRoachDB和Spanner這樣提供全局一致性的SQL存儲，以及提供聚合日誌文件查詢功能的事件流。隨着數據源不斷增加，數據規模愈來愈大，種類愈來愈多，變化速度愈來愈快，企業想要對這些數據作出更實時的響應，上述狀況也就應運而生了。對於開發人員，每種形式的數據使用方法都存在固有的優缺點，如何取捨是個難題。架構師和開發人員應該密切關注各類工具和模型提供的新功能，同時保持勤奮好學，不要徹底以對待現有工具的經常使用方法來使用新工具。咱們必須認識到數據形勢正在發生重大變革，並堅持尋找合適的策略和工具。

Terraform生態系統建設

開發人員喜歡抽象層，緣由很明顯，由於他們能夠將複雜問題封裝到抽象層中，從而集中精力處理更高層級的問題。在前幾期的技術雷達中，咱們都闡述了這種發展趨勢，不少團隊在同時使用雲和容器時都會採用這種方法。一開始他們關注的是Docker及其生態系統。而後焦點開始轉向Kubernetes。如今，咱們發現主要活動整體上都集中在基礎設施即代碼方面，尤爲是集中在Terraform生態系統上。雖然除了Terraform，咱們還推薦了其餘工具，可是它在提供商社區中的採用率仍然讓人印象深入。本期雷達的內容重點包括Terratest（用於測試基礎設施代碼），以及GoCD的新提供商（可使用Terraform配置GoCD）。

Kotlin方興未艾

Kotlin做爲一項開源語言，不只在Android環境中得到了普遍應用，並且還在向其餘環境拓展，也在技術雷達中受到了持續密切的關注。因爲不喜歡現有的語言選擇，JetBrains在內部開發了Kotlin，並隨後開源。Kotlin彷佛在各類開發人員中廣受歡迎。它常常在各類平臺和工具中用做通用甚至專用開發語言，並且在技術雷達中出現的頻率也愈來愈高。此外，咱們的項目團隊也在採用該語言（Ktor、MockK、Detekt、HTTP4K）。這個新興語言在實用性設計和先進工具中得到了普遍應用，而且造成了一個蓬勃發展的生態系統，取得了巨大的成功，對此咱們深感欣慰。

封裝邊界的泄漏

隨着「一切即代碼」理念的盛行，之前難以改變的絕大多數環節（基礎設施、安全、合規性和運營），幾乎都變得能夠經過編程來處理，這就意味着開發人員能夠採用更完善的工程實踐。然而，咱們仍然常常看到，要麼配置子系統異常複雜，要麼過分依賴於可視化編排工具，邏輯滲透到配置文件中，以YAML編寫的條件語法晦澀複雜，還有各類技術須要使用大量編排框架等狀況。隨着多語言編程、基礎設施即代碼和一切皆服務技術的出現，咱們再也不須要將各類組件都組合到單一內聚的系統中。所以，本來應位於系統邊界內的邏輯就會泄漏到編排工具、配置文件和其餘管道中。雖然有時候確有這種必要，可是咱們建議各團隊保持謹慎，考慮將此類代碼放在開發人員執行測試、版本控制、持續集成和其餘完善的工程實踐的位置。請避免將業務邏輯放在配置文件中（而且避免使用要求將業務邏輯放在配置文件中的工具），儘量減小必須執行的編排操做，不要讓編排功能主導你的系統。

象限亮點搶先看

技術

Four key metrics

採納

詳盡的DevOps現狀報告側重於對高績效組織的數據驅動型統計分析。這項研究持續多年，結果發表在Accelerate，證實了組織績效和軟件交付效能之間存在直接關聯。研究人員證明，只需四個關鍵指標就能區分低績效、中績效和高績效人員：前置時間、部署頻率、平均修復時間 (MTTR) 和變動失敗率。的確，咱們已經發現這四個關鍵指標（Four key metrics）是個簡單卻強大的工具，可幫助領導和團隊專一于衡量並改進重要的環節。實施構建流水線是一個良好開端，以便你可以捕獲四個關鍵指標，並使軟件交付價值流可見。例如，做爲 GoCD Analytics的一等公民，GoCD流水線可以衡量這四個關鍵指標。

Continuous delivery for machine learning (CD4ML) models

試驗

機器學習的持續交付 (CD4ML) 模型（Continuous delivery for machine learning -CD4ML models），將持續交付實踐應用於開發機器學習模型上，以便於隨時應用在生產環境中。該方法解決了傳統機器學習模型開發的兩個主要問題：一個是訓練模型和將模型部署到生產環境之間的週期過長，此過程一般包括將模型手動轉換爲可上線的代碼；另外一個問題是使用被過期數據訓練過的產品環境模型。

機器學習模型的持續交付流水線有兩個觸發因素：(1) 模型結構的變更； (2) 訓練與測試數據集的變更。要使其發揮做用，咱們須要對數據集和模型源代碼進行版本化。流水線一般包括用測試數據集來測試模型、按需使用H2O等工具來對模型做自動轉換、以及將模型部署到生產環境以交付價值。

Ethical OS

評估

做爲ThoughtWorks的開發人員，咱們對於工做中可能涉及到的道德問題十分敏感。隨着社會對科技的依賴程度日益增加，軟件開發團隊在制定決策時必須考慮道德問題。目前已經出現的一些工具，能夠幫助咱們思考本身所構建的軟件會在將來產生什麼影響。此類工具包括技術塔羅牌和道德風險手冊（Ethical OS），這兩類工具都得到了普遍好評。道德風險手冊爲咱們提供了一個思惟框架和一系列工具，能夠促進咱們圍繞軟件構建方面存在的道德問題展開討論。該手冊由Institute of the Future（將來研究所）和科技與社會解決方案實驗室（Tech and Society Solutions Lab）聯合編制。其中探討了一系列切實的風險，例如網癮、多巴胺經濟，並且還分析了不少值得探討的場景。

Smart contracts

評估

咱們在使用分佈式帳本技術(DLTs)方面積累的經驗越多，遇到的當前智能合約（Smart contracts ）未完善之處就越多。從理論上來看，在帳本上自動添加不能否認、不可逆的合約是個好主意。但若是在你考慮如何使用現代化軟件交付技術來開發它們，以及出現實施方式之間的差別時，問題就出現了。不可變數據是一回事，但不可變業務邏輯則徹底是另一回事！必定要想清楚是否在智能合約中包含邏輯，這一點真的很是重要。咱們已經發現，不一樣的實施方式之間存在大相徑庭的運營特徵。例如，即便合約能夠演變，不一樣平臺對這種演變的支持程度也不同。咱們的建議是，在智能合約中加入業務邏輯以前，請認真考慮，並權衡不一樣平臺的利弊。

Release train

暫緩

咱們已親眼見證，組織經過使用版本火車（Release train）概念，從極低的發佈頻率成功轉向更高頻率。版本火車是一種用於協調跨多個團隊或具備運行時依賴性組件的發佈技術。不管全部預期功能是否已準備就緒，全部版本根據一個固定且可靠的時間表發佈（火車不會等你，若是錯過，就只能等下一趟了）。雖然咱們徹底支持關於按期發佈和演示可用軟件的紀律性，但從中長期來看，咱們發現該方法存在一些嚴重缺陷，由於該方法會增長有關變動排序的臨時耦合，並且若是團隊趕着在給定時間範圍內完工，質量可能會下降。咱們更傾向於關注在必要的架構與組織的方法，來支持獨立發佈。雖然火車對於提高較慢團隊的速度很是有用，但咱們也看到它給快速團隊帶來了上限。因此咱們認爲，在使用該技術時，應儘可能當心謹慎。

平臺

EVM beyond Ethereum

試驗

以太坊虛擬機(EVM)最初是爲以太坊主網絡設計的。但現在，大多數團隊再也不想要從頭開始發明區塊鏈；相反，他們會選擇「超越以太坊的EVM（EVM beyond Ethereum ）」。咱們看到衆多區塊鏈團隊選擇對以太坊進行分支（如Quorum）或實現EVM規範（如Burrow、Pantheon），並添加他們本身的設計。這樣作不只是爲了重用以太坊的設計，還能夠利用其生態系統和開發人員社區。對於許多開發人員而言，「智能合約」的概念差很少等同於「以Solidity編寫智能合約」。雖然以太坊自己具備一些限制，但圍繞EVM生態系統的技術正在繁榮發展。

InfluxDB

試驗

時序數據庫（TSDB）已經問世一段時間了。隨着符合時序模型的使用場景愈發常見，TSDB日益成爲主流。InfluxDB仍然是TSDB的理想選擇，主要用於監控場景。TICK Stack就是一款以InfluxDB做爲核心的監控解決方案。Influx 2.0的alpha版最近引入了Flux（一種用於查詢和處理時序數據的腳本語言）。雖然Flux目前仍處於早期階段，且沒法判定能比InfluxDB得到更普遍的應用，但它承諾會比InfluxQL更強大且更具表達力，且能將時序分析工做交由數據庫來完成。然而，InfluxDB只有企業版才能提供集羣支持，所以在項目中須要留意這個限制。

Istio

試驗

Istio正逐漸成爲將微服務生態系統付諸應用的標準基礎設施。其開箱即用的橫切關注點的實現，已經幫助咱們快速實現了微服務。這些橫切關注點實現包括：服務發現、服務之間和從請求到服務之間的安全性、可觀測性（包括遙測和分佈式跟蹤）、滾動發佈和彈性。Istio是咱們一直使用的服務網格技術的主要實現平臺。咱們很是享受它的每個月發佈及無縫升級所帶來的持續改進。咱們使用Istio來啓動項目，從一開始就能得到可觀測性（跟蹤和遙測）和服務之間的安全性。咱們正密切關注其在網格內外各處服務之間身份驗證方面所作的改進。此外，咱們但願看到Istio爲配置文件創建最佳實踐，從而在爲服務開發人員提供自主權和爲服務網格運營商提供控制權之間達到平衡。

Hot Chocolate

試驗

GraphQL生態系統和社區正不斷髮展。Hot Chocolate是用於.NET（包括新的core和原先的傳統框架）的GraphQL服務器。該平臺可用於構建和託管schema，並能用於處理針對這些schema的查詢。Hot Chocolate的開發團隊近期增添了schema拼接功能，容許從單個入口點跨多個schema（從不一樣位置聚合而成）進行查詢。雖然該功能會被以多種方式誤用，但仍是值得對其進行評估。

Knative

評估

無服務器架構的應用，讓FaaS編程風格在開發人員之間愈來愈普及。該架構經過獨立構建和部署的函數，幫助開發人員專一於解決核心業務問題。這些函數能響應事件、運行業務流程、在流程中生成其餘事件，完成任務後隨即消失，再也不消耗資源。之前，AWS Lambda或Microsoft Azure Functions等專有無服務器平臺已實現這種編程範式。Knative是基於Kubernetes的開源平臺，用來運行FaaS工做負載。Knative有幾點突出之處：開源且適用於任何供應商；實現了CNCF無服務器工做小組白皮書中所定義的無服務器工做流；經過實現符合CNCF CloudEvents規格的事件接口，來確保跨服務的互操做性；尤爲重要的是，它可以解決在運維混合FaaS與長期運行的容器化架構時所遇到的常見挑戰。該平臺易與Istio和Kubernetes集成。例如，經過在不一樣版本的函數之間切換流量，開發人員能夠利用Istio實施金絲雀發佈策略。對於處在相同Kubernetes環境中的長期運行的容器服務和FaaS程序，開發人員均可以享受到Istio所提供的可觀測能力。咱們預計，Knative開源事件接口將繼續支持更多底層源和目的事件的集成。

工具

UI dev environments

採納

隨着愈來愈多的團隊擁抱DesignOps，該領域的實踐和工具也日漸成熟。UI開發環境專一於用戶體驗設計師與開發人員之間的協做（UI dev environments），爲UI組件的快速迭代提供了綜合環境。目前在該領域可用的工具包括：Storybook、React Styleguidist、Compositor和MDX。這些工具既能夠在組件庫或設計系統的開發過程當中單獨使用，也能夠將其嵌入到web應用程序中使用。經過使用這些工具，許多團隊在開發準備工做中縮短了UI反饋週期並改善了UI工做的時間。因而，使用UI開發環境成爲了咱們合理的默認選擇。

batect

試驗

大量的精力仍然被浪費在部署本地開發環境和排查「works on my machine」（在個人機器上能夠工做）的問題上。多年來，咱們的團隊已經採用「檢查並實施」的方法，使用腳本化方法來確保本地開發環境的配置始終一致。Batect是由ThoughtWorker開發的一款開源工具，可幫助輕鬆搭建和共享基於Docker的構建環境。Batect做爲構建系統的入口點腳本，可以啓動容器來執行徹底不依賴於本地配置的構建任務。對構建配置和依賴項的更改僅經過源碼管理便可共享，無需在本地機器或CI代理上進行任何更改或安裝。在該領域的其餘工具中，咱們偏向於使用Cage，但咱們也看到batect正在以符合咱們團隊需求的方向迅速發展。

Detekt

評估

Detekt是一個適用於Kotlin的靜態代碼分析工具。它可以發現代碼中的壞味道和複雜性。你能夠經過命令行運行它，也可使用其插件集成一些熱門的開發者工具，例如Gradle（用於在項目構建時執行代碼分析）、SonarQube（用於除靜態代碼分析外的代碼覆蓋率統計）和IntelliJ等。Detekt可以給Kotlin應用的構建流水線錦上添花。

Humio

評估

在日誌管理領域，Humio是一款相對較新的工具。該工具徹底從零開始構建，經過基於定製設計的時序數據庫的內置查詢語言，在日誌提取和查詢方面性能很是快。從提取、可視化和報警提醒的角度來看，該工具可以與幾乎全部工具相集成。日誌管理領域已被 Splunk 和 ELK Stack主導，因此，有替代選擇也是一件好事。咱們將持續關注 Humio 的發展。

Kubernetes Operators

評估

咱們對於Kubernetes對行業產生的影響興奮不已，但也擔憂隨之而來的運維複雜度。保持Kubernetes集羣啓動並運行、管理在該集羣上部署的軟件包都須要特殊技能和時間。升級、遷移、備份等運維流程常常會是一項全職工做。咱們認爲Kubernetes Operator會對下降複雜度起到關鍵做用。該框架提供了一套標準機制，爲在Kubernetes集羣中運行的軟件包描述了自動化運維流程。雖然Operator由RedHat發起和推廣，但多個社區爲經常使用開源軟件包（如Jaeger、MongoDB和Redis）開發的Operator已初露頭角。

語言&框架

Apache Beam

試驗

Apache Beam是一個開源的統一編程模型，用於定義和執行數據並行處理流水線的批處理與流式傳輸。Beam模型基於數據流模型，容許咱們以優雅的方式表達邏輯，以便在批處理、窗口化批處理或流式傳輸之間輕鬆切換。大數據處理生態系統已經取得了長足發展，這可能會致使人們難以選擇正確的數據處理引擎。容許咱們在不一樣運行程序之間切換，這是選擇Beam的一個關鍵緣由。幾個月前，它支持了Apache Samza，這是除Apache Spark、Apache Flink和Google Cloud Dataflow以外的又一個新的運行程序。不一樣運行程序具備不一樣能力，且提供輕便的API是一項困難的任務。Beam將這些運行程序的創新主動應用於Beam模型，並與社區合做以影響這些運行程序的路線圖，從而試圖達到微妙的平衡。Beam具備包括Java、Python和Golang多種語言的SDK。咱們也成功使用了Scio，它爲Beam提供了Scala包裝器。

Puppeteer

試驗

與Cypress和TestCafe同樣，Puppeteer也是備受咱們團隊推崇的一款Web UI測試工具。Puppeteer可以對無頭瀏覽器進行細粒度控制，生成時間軸信息，以用於性能診斷等。咱們的團隊發現，相較其餘基於WebDriver的同類工具，Puppeteer更加穩定、快速和靈活。

Room

試驗

Room是一個數據持久化庫，用於在Android上訪問SQLite。它支持使用最小限度的樣板代碼進行數據庫訪問，同時經過編譯時SQL校驗使數據庫訪問更加穩健。令咱們開發人員感到滿意的是，使用LiveData後，Room可以與可觀察查詢完整集成。Room是Android Jetpack組件之一，旨在簡化Android應用開發。

Rust

試驗

Rust最近一次在技術雷達中出現是2015年，自那以來，咱們看到開發者對Rust的興趣在逐漸提高。咱們的一些客戶正在使用Rust語言，尤爲在圍繞基礎設施工具方面的使用最爲常見，而在高性能的嵌入式設備中也能夠見到Rust的身影。不斷完善的生態系統以及語言自己的改進推進了人們的興趣提高。語言的改進方面，包括了直接的性能加強，也包括了直觀表現力的提升，例如非詞法做用域的更改。大多數重大變化都包含在去年12月發佈的Rust 2018標準中。

fastai

評估

fastai是一個開源Python庫，可以簡化對快速且準確的神經網絡的訓練。它基於PyTorch構建，已成爲備受咱們數據科學家歡迎的工具。fastai可簡化模型訓練中的難點，如預處理、使用少許代碼加載數據。該庫根據深度學習最佳實踐構建而成，對計算機視覺、天然語言處理(NLP)等提供開箱即用的支持。創始人的動機是爲深度學習建立易於使用的庫，使之成爲一個改進版的Keras。GCP、AWS和Azure很快便接納了fastai，將其包含在機器學習的鏡像中。fastai的建立者意識到Python在速度和安全方面的限制，已宣佈接納Swift做爲深度學習的替代語言。咱們將密切關注其進展。

以上是咱們在最新一卷技術雷達中隨機摘取的幾個Blip，欲獲取整版技術雷達，請點擊這裏進行下載！

---

5月9日，ThoughtWorks技術委員會成員、中國區區塊鏈實踐負責人劉尚奇還將在線上爲你們帶來新一期雷達解讀，細述四大主題趨勢，解析重點技術條目，席位有限，歡迎掃碼參與～

---

更多精彩洞見，請關注微信公衆號：ThoughtWorks洞見