技術雷達是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技術委員會成員、中國區區塊鏈實踐負責人劉尚奇還將在線上為大家帶來新一期雷達解讀，細述四大主題趨勢，解析重點技術條目，席位有限，歡迎參與～
技術雷達報名鏈接（手機微信打開）：http://t.cn/EaQgnyJ
技術雷達完整版下載鏈接：https://www.thoughtworks.com/cn/radar
更多精彩洞見，請關注微信公眾號：ThoughtWorks洞見
閱讀更多 ThoughtWorks 的文章
