從第19期技術雷達看 DevOps 的發展趨勢

2018年下半年的技術雷達發佈了。看過的朋友可能和個人感受同樣，會發現大部分條目都是和微服務和 DevOps 相關，但這些條目散落在不一樣的象限裏。本文將這些散落在不一樣象限的條目採用如下 5 個主題進行重組：

1. DevOps 合做新實踐
2. 雲計算新實踐
3. 容器新技術
4. 微服務及其誤區
5. 安全

特別要提出的是，這期技術雷達採納了 2018 年的 DevOps 報告 中的四個關鍵指標(FOUR KEYMETRICS):前置時間，部署頻率，平均恢復時間(MTTR)和變動失敗百分比。而這四個關鍵指標也是業界度量 DevOps 效果的統一方式。

每一個指標都創造了一個良性循環，並使團隊專一於持續改進:縮短交付週期，減小浪費的活動，從而使你能夠更頻繁地部署，進而改進他們的實踐和自動化流程。經過更好的實踐，自動化和監控能夠提升你從故障中恢復的速度，從而下降故障頻率。

DevOps 的合做

如何更好的在組織內合做是 DevOps 實踐中永恆不變的的話題。隨着 DevOps 合做理念的深刻，合做的範圍愈來愈越廣，隨之帶來了新的問題和挑戰。這期的技術雷達介紹瞭如下幾方面的合做：

1. 和外包團隊/供應商的 DevOps 合做
2. 和用戶/客戶/UX設計師的合做
3. 分佈式團隊之間的合做

和外包團隊的 DevOps 合做

而隨着 DevOps 應用的加深，會不可避免的碰到組織結構上帶來的問題。特別是和外包方的合做，會影響組織的 DevOps 表現。這樣的合做每每充滿了漫長繁冗且火藥味十足的會議和合同談判，這是 DevOps 運動中不但願看到的可是又沒法避免的問題。在 2018 年的 DevOps 報告中看到外包會帶來效能降低——「低效能團隊將整部分職能進行外包的可能性幾乎是高效能團隊的 4 倍，這些 外包功能包括測試或運維等等。」

看到這裏，千萬不要得出「不要用外包的結論」。這裏說得是不要「職能的外包」，而「端到端的外包」（End-2-End OutSourcing）則會免除這種顧慮。不少業界一流的 IT 服務企業都提供端到端的 IT 外包服務，你只須要告訴它們你要DevOps，它們會用最有效的方式交付給你。與供應商一塊兒增量交付(INCREMENTAL DELIVERY WITH COTS (commercial off-the-shelf)) 就是這期技術雷達中提出的和外包商一塊兒進行 DevOps 策略之一。與供應商的作端到端的 DevOps 性質的外包另一個優勢則是這樣的供應商適合作「長期合做夥伴」來補充你業務、IT 等多樣性的不足，甚至可以幫你培訓員工。

而隨着組織開始採用四個關鍵指標，這對對供應商的要求也愈來愈高，但盈利空間相對愈來愈小。和任何行業同樣，成本的下降和效率的提高永遠是不變的主節奏。外包也要提高本身的能力水平以跟上技術發展的節奏，這是不可避免的成本。

可是，和外包方的合做仍然是在 DevOps 轉型過程當中不可避免的痛苦，能夠採用一些方式減輕這種痛苦。例如這期技術雷達中介紹的「風險相稱的供應商策略(RISK-COMMENSURATE VENDOR STRATEGY) 」，它鼓勵在高度關鍵系統中維持其供應商的獨立性。而那些相對不過重要的業務能夠利用供應商提供的成熟解決方案，這可讓企業更容易承受失去該供應商所帶來的影響。這不光是說 IT 產品供應商，一樣也指的 IT 服務供應商。

「邊界購買（BOUNDED BUY）」就是這樣一種實踐，在採購產品中即只選擇模塊化、解耦的，且 只包含於單一業務能力(Business Capability)的限界上下文(Bounded Context)中的廠商產品。應該將這種對 模塊化和獨立交付能力的要求，加入對供應商選擇的驗收標準中去。也能夠將一小部分業務的端到端維護外包出去，在得到靈活性的同時，又得到高效。

和 UI 的合做 ——DesignOps

DevOps 的目標就是儘量的縮短最終用戶想法到代碼之間的距離，避免傳遞過程當中的信息失真。特別是用戶的反饋，因而有了 DesignOps 實踐。這個領域的實踐和工具也日漸成熟。這期的技術雷達介紹的一整套支持 UI 的開發環境(也稱爲UI DEV ENVIRONMENTS)專一於用戶體驗設計人員與開發人員之間的協做，例如 :Storybook ，react-styleguidist，Compositor 及 MDX。這些工具大部分圍繞 React 的生態圈產生。既能夠在組件庫或設計系統的開發過程當中單獨使用，也能夠嵌入到 Web應用項目中使用。

分佈式團隊的合做

隨着組織的擴大，分佈式的團隊是一個沒法迴避的問題。你極可能會和不一樣地理位置的其它同事一塊兒開發，例如：不一樣的辦公樓，不一樣的城市，甚至是不一樣的國家。但這些問題不是 DevOps 的阻礙，能夠經過一系列的工具來彌合地理上的界限。

Visutal Studio Code 目前是最受歡迎的編輯器和開發環境。而 VS Live Share 給分佈式的跨地域協做開發的能力，它是用於 Visual Studio Code 與 Visual Studio 的插件。提供實時合做編輯與調試代碼、語音通話、共享終端和暴露本地端口等功能，可以減小遠程結對編程時遇到的障礙。開發人員能夠在使用Live Share 協做時沿用本身的編輯器配置，包括主題、快捷鍵和擴展。

雲計算新實踐

若是你仔細看技術雷達，這期的技術雷達把 AWS，Azure 和 Google Cloud Platform 這三個世界上最大的雲計算供應廠商放到了 Trail（試驗）象限。這說明在採用雲計算的時候，須要注意防止被雲供應商綁定。從這個角度來講，Kubernetes 這樣平臺無關的技術要更好。

設置多雲帳號(MULTI-ACCOUNT CLOUD SETUP)能夠避免被單一的雲供應商綁定，能夠平衡的結合採用多個雲平臺的優點來動態的配置你的雲計算經驗。

CHAOS KATAS 是一項爲基礎設施和平臺工程師提供技能培訓和提高的技術。它將 Kata （我我的更傾向於把 Kata 翻譯爲 套路）的方法論與Chaos Engineering 的相關技術(具體指在受控環境中模擬故障和停機)進行結合，對工程師進行系統化教學和培訓。這裏的 Kata 是指觸發受控故障的代碼模式，它容許工程師發現問題，恢復故障，開展過後分析並找到根本緣由。工程師經過重複執行Kata能幫助他們真正掌握新的技能。

用基礎設施即代碼提高基礎設施的質量

管理雲計算資源最有效的形式是採用基礎設施即代碼技術。在這一方面，早期的 Chef，Puppet 已被 Ansible、Salt 等取代。然後繼之秀 Terraform 則簡化了不少的雲計算平臺上的基礎設施配置工做。如今，Terraform 已經成爲公有云基礎設施即代碼的第一選擇。這期的技術雷達介紹了Terragrunt，它是Terraform 的一個輕量級的封裝，用來落地《 Terraform: Up and Running 》書中主張的實踐。固然，在採用它以前你能夠先讀一下這本書。

若是你使用了 AWS，而且向經過編程的方式生成基礎設施即代碼。你可使用Troposphere，Troposphere 是一個Python 庫，可使用 Python 代碼生成 JSON 格式的 CloudFormation 描述。這樣的代碼的複用性和設計都會很好，同時它也有類型檢測、單元測試以及 DRY 組合 AWS 資源等功能。�

在雲原生的環境下，跨平臺，跨實踐的基礎設施即代碼技術將成爲下一個基礎設施即代碼的發展方向。Pulumi就是這樣一款「雲原生即代碼」工具，它提供了一個雲原生開發平臺，爲全部的雲原生應用經過一致的編程模型和統一的DevOps實踐，幫助團隊大幅提高生產力，並以很快的速度將代碼遷移到雲中。

結合往期的技術雷達，能夠看出，在有效的採用基礎設施即代碼的技術上，除了版本化和自動化之外，基礎設施即代碼正在向可測試性和合規性的方向發展。對基礎設施質量的度量和檢測能夠經過基礎設施即代碼來實現。而除了公有云平臺，不多能夠見到企業對私有的基礎設施質量的關注。和軟件產品同樣，基礎設施也會存在技術債，而這些技術債會引起應用程序的技術債的連鎖效應。好比，你採用了老舊的設備和老舊的操做系統，在缺少管理的狀況下，網絡、安全甚至是性能問題愈來愈凸顯，而系統會愈來愈脆弱。

Kubernetes 和容器

Kubernetes 已是容器生態的核心，由於除了 Docker 之外，還有其它的替代容器方案能夠選擇。但編排方案的選擇卻不會太多。爲了保持容器鏡像的大小，你們每每會採用 Alpine 和 Busybox 這樣袖珍的鏡像做爲基礎鏡像。避免安裝和配置那些無用的軟件包和SDK。如今有了 DISTROLESS DOCKER IMAGES 這樣的選擇，能夠被翻譯作 「非發行版的 Docker 鏡像」，它由 Google 開發，並給每種語言運行時都創建了�發行版無關的鏡像，兼顧了安全性和大小兩方面。

在 Kubernetes 運維方面，這期的技術雷達新增了兩個工具。Kube-Bench 和 Heptio ARK。前者是大名鼎鼎的 K8S 機器學習社區 Kubeflow 推出的一款基礎設施配置掃描工具，基於 K8S的 CIS 評分自動檢查 Kubernetes 配置，涵蓋用戶身份驗證，權限控制和數據安全等方面。後者是Kubernetes 跨雲的解決方案廠商 Heptio 推出的一個集羣和持久化卷的災難恢復管理工具。使用 Ark 能夠顯著縮短基礎架構發生故障時的恢復時間，還能輕鬆地將 Kubernetes 資源從一個集羣遷移到另外一個集羣，或者複製生產環境用於測試和排錯。Ark支持主流的雲存儲提供商(包括 AWS ，Azure 和 GoogleCloud )，而且從版本0.6.0開始，提供了插件系統用於兼容其餘備份與卷存儲平臺。雖然 GKE 等 Kubernetes 託管環境已經提供了這類服務，但若是須要自行運維 Kubernetes ，不管是在本地仍是雲端，都請仔細考慮使用 Heptio Ark 進行災難恢復。

Rook 是一款運行在Kubernetes集羣中的開源雲原生存儲編排工具，如今仍然在CNCF 進行孵化。與Ceph集成以後的Rook，能將文件、塊和對象存儲系統引入到 Kubernetes 集羣中，並能與使用這些存儲的其餘應用和服務一塊兒無縫地運行。經過使用一些 Kubernetes operator，Rook能夠在控制層上編排Ceph，這樣就能夠避免擠佔應用程序和Ceph之間的數據通道。

Kubernetes 一直是 無服務器架構（Serverless Architecture）的理想平臺，圍繞着 Kubernetes 已經有了不少 Serverless 解決方案，如 Kuberless 和 OpenFaaS。Knative 是 Google 推出的基於 Kubernetes Serverless 方案，你能夠把它部署在任何 Kubernetes 集羣上。

Service Mesh 提供一致的發現、安全性、跟蹤、監控和故障處理，而無需共享API網關或ESB等設施。典型的實現是將每一個服務進程和輕量級反向代理以Side-Car 的方式一塊兒部署，反向代理進程可能在單獨的容器中。這些代理與服務註冊表，身份提供者，日誌聚合器和其餘服務進行通訊。服務互操做性和可觀測性是經過此代理的共享實現而不是共享運行時實例得到的。

隨着集中式的微服務網關和服務註冊/發現機制的逐漸臃腫，Service Mesh 會接起微服務規模化的接力棒。隨着 Linkerd 和 Istio 等開源項目將逐步成熟，這使得 service mesh 更容易實現。目前 Istio 仍遭受了來自性能方面的擔憂，但我相信在某些場景下，這些性能損耗是能夠被複雜性平衡的。

Kubernetes 生態圈的發展一直圍繞着微服務進行的。因此，結合微服務技術的發展更能夠看清Kubernetes的發展軌跡。

微服務及其誤區

微服務的實踐正在渡過深水區，判斷的依據很簡單：關於微服務的工具出現的愈來愈少，而實踐和經驗愈來愈多。這代表不少不會有不少新的通用問題須要解決。事件風暴(EVENT STORMING) 被放入了「採用」環中，這意味着事件風暴將做爲微服務實踐的核心技術之一。事件風暴是一項團隊活動，旨在經過領域事件識別出聚合根，進而劃分微服務的限界上下文。在活動中，團隊先經過頭腦風暴的形式羅列出領域中全部的領域事件，整合以後造成最終的領域事件集合，而後對於每個事件，標註出致使該事件的命令（Command），再而後爲每一個事件標註出命令發起方的角色，命令能夠是用戶發起，也能夠是第三方系統調用或者是定時器觸發等。最後對事件進行分類整理出聚合根以及限界上下文。事件風暴還有一個額外的好處是能夠加深參與人員對領域的認識。

在微服務的應用中，分佈式追蹤一直是一個困擾人們好久的問題。CNCF 的 Jaeger 的機制一樣來源於谷歌的 Dapper，並遵循 OpenTracing 。它在 Kubernetes 集羣中安裝它也很簡單，它能夠和Istio 配合使用，在 Kubernetes 集羣中與 Envoy集成進行應用程序追蹤。而 CNCF 所提供的工具漸漸會和 Spring Cloud 這種微服務全家桶的解決方案結合，變成將來微服務架構的基準參考模型。

除了 Java 社區之外，其它語言的社區也躍躍欲試。例如這一期技術雷達介紹的 Ocelot，它是基於.NET Core實現的輕量級API網關項目，它能夠經過輕鬆的配置來實現路由轉發、請求聚合、服務發現、認證受權、限流熔斷、負載均衡等特性，它還集成了Service Fabric、Consul、Eureka等功能。目前 Ocelot 的功能已經至關完整，它在.NET Core社區的活躍度也很高。目測可以做爲將來 .NET 社區微服務實踐的首選。

而在 Python 社區，出現了一個超輕量級的微服務框架 NameKo，它也是 Flask的 替代方案。與 Flask 不一樣的是 Nameko 只包含了 WebSocket、HTTP、AMQP 支持等有限功能。我很是喜歡這種簡單而輕量的框架，若是你採用 Python 做爲微服務的實現語言，你能夠考慮考慮它。

JavaScript 社區曾經有一個從前端到後端「一統天下」的設想。也出現了 MEAN 這樣的全棧 Javascript框架。如今 F# 社區出現了一個有力的競爭者：SAFE 。SAFE 技術棧是 Suave、Azure、Fable 和 Elmish 的簡稱。SAFE 囊括了一系列技術，造成了先後端一致的 Web 開發技術棧。SAFE 在服務端和瀏覽器端都使用了 F# 語言，所以注重於異步函數式類型安全的編程機制。它不只提供了一些提升開發效率的功能好比熱加載; 還容許替換技術棧裏的某些模塊，例如服務器端 Web 框架或雲提供商。它頗有但願成爲微軟技術棧下 Serverless 微服務架構的候選者。

微服務的誤區

隨着微服務愈來愈火，不少組織開始盲目的追求微服務架構。但不少團隊都把架構經過把簡單的 API 進行復雜的整合使架構更加難以維護。它用運維複雜性換取了開發的複雜性。然而，這須要堅實的自動化測試，持續交付和 DevOps 能力做爲支撐。

這期技術雷達提出的分層式微服務架構(LAYERED MICROSERVICES ARCHITECTURE)的組織是一種反模式，他們在某些方面存在着明顯的矛盾。這些組織都陷入了以技術角色爲主來劃分服務的誤區，好比，用戶體驗API、進程 API 或系統 API等。這樣會致使業務變動仍然會有緩慢而昂貴的多團隊合做。

另一點是，當中臺戰略逐漸開始流行後，會致使前臺團隊和後臺團隊被從技術上分開，而缺少了微服務所須要的總體業務能力。中臺更多強調的是內部應用的產品化和 SaaS 化能力。而不只僅是割裂爲獨立的微服務。這樣，你須要額外的一箇中間層來作前臺和中臺之間的轉換。而這樣一箇中間層，不管是放到前臺和中臺都是不合理的。我仍然推薦圍繞業務能力組建一個端到端的微服務團隊。

因爲微服務不少都支持基於事件的異步調用方式，這也影響到了前端用戶體驗的設計。這就是在面向用戶的工做流中使用請求 — 響應事件 (REQUEST-RESPONSE EVENTS IN USER-FACING WORKFLOWS)的系統設計。這樣一來，要麼UI被阻塞，要麼用戶就必須等頁面收到響應消息後從新加載。作出這類設計的主要依據每每是爲了性能或是爲了用統一的方式來處理後端之間的同步和異步通訊。但這樣作會在開發、測試和運維上所增長沒必要要的複雜度，遠遠超過了採用這種統一方式帶來的好處。因此，在用戶可接受的場景下，直接使用同步HTTP 請求來處理後端服務之間的同步通訊，而沒必要改爲事件驅動的設計。若是設計的精妙，使用HTTP通訊不多會成爲分佈式系統的瓶頸。

微服務架構的一個顯著特徵是系統組件和服務是圍繞業務能力進行組織的。不管系統規模大小，微服務都須要將系統功能和信息進行有意義的分組和封裝，以便拆分後的微服務能彼此獨立地交付業務價值。微服務是從業務角度對架構的從新審視，而之前的服務架構方式會從技術角度組織服務。

安全

技術雷達歷來沒有像這一期有這麼多的安全相關的內容。今年的信息安全事件頻發，並和技術的發展結合在一塊兒，每每給人們一種「新技術必定會帶來安全問題」的錯覺。而安全的主要因素是人，工具只是下降工做量和節省工做時間的一種方式，它不能替代安全設計和安全活動自己。我把安全單獨列爲一節主要是爲了可以使您對安全實踐有一個端到端的認識。

運維相關的安全實踐和工具

對敏感數據保持適當的控制是至關困難的，尤爲是在出於對數據備份和恢復的目的而將數據複製到主數據系統以外的時候。密鑰粉碎(CRYPTO SHREDDING)是經過故意覆蓋或刪除用於保護該數據的加密密鑰來使敏感數據沒法讀取的作法。例如，可使用隨機密鑰對數據庫中客戶我的詳細信息表的全部記錄進行一對一加密，而後使用另外一張表來存儲密鑰。若是客戶行使了「被遺忘的權利」，您能夠簡單地刪除相應的密鑰，從而有效地「粉碎」加密數據。當你有信心對小規模加密密鑰集合維持適當控制，但對較大數據集的控制信心不足時，此項技術很是有效。

在雲計算平臺上維護基礎設施首要的工做就是設立一個安全的框架，其次須要實踐和工具來進行安全檢查。

繼混沌工程（Chaos Engineering）以後，安全混沌工程(Security Chaos Engineering) 也發展的愈來愈好，使用此技術的團隊確信他們的安全策略足以應對常見的安全故障模式。不過，這方面的實踐僅有 ChaoSlingr一個工具，且僅支持 AWS 平臺。就像以前提到的 Chaos Engineering Katas，我相信將來會有 Security Chaos Engineering Katas 做爲平常安全的練習。

隨着雲計算平臺基礎設施即代碼的複雜度提高，相應的安全掃描工具也應運而生。Watchmen是個採用 Python 編寫的工具，它爲由交付團隊自主擁有和運營 AWS 帳戶配置提供基於規則驅動的掃描。技術雷達所提到的 Scout2 已經再也不維護，它被遷移到了ScoutSuite，目前支持 AWS，但即將包括 Azure 和 Google Cloud Platform。我強烈建議你將這些工具集成到你的基礎設施流水線（Pipeline for Infrastructure）裏。

開發相關的安全實踐和工具

咱們已經經歷了一些把密碼存儲到代碼庫上致使的數據泄露實踐。將安全憑據或其餘機密提交到源代碼倉庫是一個主要的攻擊向量。GIT-SECRETS 是防止將密碼或其餘敏感信息提交到 git 倉庫的小工具。AWS 實驗室也提供了一個同名的工具，git-secrets 內建支持常見的 AWS 密鑰和憑據，也能夠爲其餘的提供商進行快速配置。

SNYK是一個能夠查找、修復及監控 npm 、Ruby 、Python 、Scala 、Golang 、.NET 、PHP 、Java 與 Docker 依賴樹中漏洞的平臺。將 Snyk 加入構建流水線後，它會基於一個託管的漏洞數據庫，持續地監控和測試你的庫依賴樹。在發現漏洞時，還能夠給出能夠解決該安全問題的最小的依賴版本。目前它支持多種 Git 倉庫服務和 PaaS 平臺服務。

若是你想對 Web 應用進行安全掃描，你能夠採用 Archery，它是一個開源的安全工具，並正在將其與其餘工具(包括 Zap )相結合，輕鬆地將安全工具集成到構建與部署系統中。你也能夠經過 Archery 的工做面板，跟蹤漏洞及應用程序和網絡的安全掃描結果。

一樣，隨着微服務的流行，它的安全問題也被提高到了最高的高度。SPIFFE (Secure Production Identity Framework For Everyone， 適用於全部人的安全生產身份框架) 以特製X.509證書的形式爲現代生產環境中的每一個工做負載提供安全標識。 SPIFFE消除了對應用程序級身份驗證和複雜網絡級ACL配置的需求，Istio 默認就採用了 SPIFFE。

參考

www.thoughtworks.com/cn/radar/

cloudplatformonline.com/2018-state-…

puppet.com/resources/w…