本文已于5月2日同時發表于 ThoughtWorks 洞見，原標題為《DevOps 發展的9個趨勢》
DevOps 包含了太多方面的技術和實踐，很難通過一個統一的工具鏈來描述其發展。即便如此，我們仍然可以從 ThoughtWorks 技術雷達的條目變動中看出一些趨勢。今年，我有幸作為主編參與了最新一期技術雷達的譯制，作為 DevOps 的愛好者，十分高興能在這一過程中看到DevOps 未來發展的幾個趨勢，總結成了這篇文章。
趨勢1：微服務目前仍然是 DevOps 技術應用和發展的主要領域
微服務將單塊應用系統切割為多個簡單獨立的應用。從技術上說，這是通過工具把應用程序的內部復雜度轉化為外部復雜度，需要一系列工具支撐微服務本身以及服務之間的通信。從組織上說，微服務團隊要滿足“快速發布，獨立部署”的能力，則必須具備 DevOps 的工作方式。
如何拆解微服務一直是微服務技術應用的最大難點之一，領域驅動設計是比較理想的微服務拆解方法論。社會化代碼分析幫助團隊通過更精確的數據找到更加合適的拆分點。CodeScene是一個在線服務，它能幫助識別出熱點和復雜且難以維護的子系統，通過分析分布式子系統在時間上的耦合發現子系統之間的耦合。此外，它還能幫你認識組織中的康威定律，這會大大降低微服務解耦的難度。
此外，微服務系統本質上是一個分布式系統，分布式系統之間的通信一直是很重要的問題。本期介紹的Kafka Streams和OpenTracing就是這類技術的條目。Kafka 作為一個成熟的分布式消息系統已經被廣泛采用，而 Kafka Streams 則將最佳實踐以“庫”的方式呈現給開發人員，使得操作 Kafka 更加自然和簡單。而 OpenTracing 則彌補了跨越多個微服務之間請求追蹤的空白。
另一方面，無服務器風格的架構（Serverless architecture ）把 DevOps 技術在微服務領域的應用推向極致。當應用程序執行環境的管理被新的編程模型和平臺取代后，團隊的交付生產率得到了進一步的提升。一方面它免去了很多環境管理的工作，包括設備、網絡、主機以及對應的軟件和配置工作，使得軟件運行時環境更加穩定。另一方面，它大大降低了團隊采用 DevOps 的技術門檻。然而，端到端的交付以及微服務中的函數管理問題日漸突出，盡管AWS API gateway和AWS Lambda幾乎成了 Serverless 架構的代名詞，但這二者結合的開發者體驗并不佳。于是出現了Serverless framework和CLAUDIA這樣的管理工具。
AWS Lambda 帶來的優勢也深深影響了企業級應用領域，Apache OpenWhisk就是企業級無服務器領域的選擇之一，它使得企業級應用也可以采用無服務器風格的架構構建應用程序。
在微服務端到端交付流程上，Netflix 開源了自家的Spinnaker，Netflix 作為微服務實踐的先鋒，不斷推出新的開源工具來彌補社區中微服務技術和最佳實踐的缺失。 而Spring Cloud則為開發者提供了一系列工具，以便他們在所熟悉的 Spring 技術棧下使用這些服務協調技術(coordination techniques)，如服務發現、負載均衡、熔斷和健康檢查。
而在微服務的安全上，最常見的需求之一 是通過身份驗證和授權功能來保護服務或 API 。 這部分功能往往是最重要且不斷重復構造的。而Keycloak就是一個開源的身份和訪問管理解決方案，用于確保應用程序或微服務的安全。且幾乎不需要編寫代碼，開箱即用。它支持單點登錄，社交網絡登錄和標準協議登錄(如 OpenID Connect ， OAuth2 和 SAML 等)。
趨勢2：以 Docker 為核心的數據中心方案逐漸走向成熟
在過去的兩年，Docker 社區有了突飛猛進的發展，似乎每期技術雷達都會出現 Docker 相關的條目。而 Docker 往往和 DevOps 聯系起來，被認為是推動 DevOps 發展的殺手級工具，以至于有些人會以團隊是否采用 Docker 作為團隊是否具備 DevOps 能力的標志。
而這一社區的創新數量則日漸平緩。一方面，開源社區激烈的競爭淘汰了一部分技術。另一方面，以 Docker 為中心的完整數據中心解決方案在不斷的整合開源社區的零散工具并形成最佳實踐。為端到端的開發和運維提供更完整的交付體驗，各大廠商也相繼開始推廣自己的企業級整體收費解決方案，這表明 Docker 的使用已經走向成熟。
在本期的技術雷達里的條目中出現了Mesosphere DC/OS，這是構建統一技術棧數據中心的一個征兆。在這方面Docker EE和Rancher都是非常有力的競爭者。根據我的判斷，在未來的 Docker 社區里，統一容器化數據中心的競爭者將會進一步減少。而之前的私有云方案則慢慢會被“以 Docker 為核心數據中心級全棧交付”取代。
趨勢3：不完整的 DevOps 實踐阻礙著 DevOps 的發展
很遺憾看到單一持續集成實例和不完整的持續集成（CI Theatre）這樣的條目出現在技術雷達里。可以感到企業應用 DevOps 技術的緊迫性。這同時也暴露了 DevOps 領域里“缺乏門檻較低且成熟的 DevOps 實踐”的問題。
大部分企業在 DevOps 轉型中僅僅關注到了工具的升級。卻忽視了價值流、生產流程中各個活動中的最佳實踐以及 DevOps 團隊文化的構建，這會使團隊陷入 “已經完成 DevOps 轉型的假象 ”，而停止了團隊的自我改進。
DevOps 的實踐包含組織改進和技術升級兩個部分，技術往往是最容易的部分。而缺乏組織改進的技術提升往往很難給組織帶來質的飛躍。具備 DevOps 文化的團隊則會不斷反思和學習，通過共擔責任和相互合作不斷完善組織的 DevOps 實踐。
趨勢4：領域特定的 DevOps 實踐開始出現
DevOps 的最早實踐來自于互聯網企業的 Web 應用，相應的思想被引入企業級應用并促進了一系列工具的發展。雖然并不是每一種應用軟件交付形式都適合 DevOps，但隨著 DevOps 的工具不斷成熟。其它領域的 DevOps 實踐也開始嘗試借鑒 Web 應用領域的自動化工具，并逐漸形成領域級的 DevOps 實踐。
在人工智能領域，TensorFlow就是這樣一個例子，它可以有多種 DevOps 友好的安裝和部署方式 ，例如采用 Docker 進行部署。
在區塊鏈領域，超級賬本(HYPERLEDGER) 就是這樣一個例子，它提供了一套工具和服務，結合 DevOps 相關技術和實踐形成了一個完整的解決方案。
隨著 DevOps 相關概念和技術不斷向各個產業領域的深入發展，可以看到 DevOps 技術和實踐帶來的巨大影響力。然而，每個技術領域都有自己所關注的特性，并不是以往的 DevOps 實踐可以全覆蓋到的，這恰恰成為了 DevOps 技術和實踐發展的契機。我很期待領域特定的 DevOps 技術實踐給 DevOps 帶來的發展。
趨勢5：采用 DevOps 進行技術債務重組和技術資產管理
技術債務類似于金融債務，它也會產生利息，這里的利息其實就是指由于魯莽的設計決策導致需要在未來的開發中付出更多的努力。投資銀行業往往采用多種金融工具組合的方式來處理企業的不良債務。而清理技術債務的實踐和工具卻乏善可陳。
技術債務不光阻礙了企業通過新技術帶來便利，還使企業償還技術債務所承擔的成本越來越高，例如技術人才的流失，技術利息等綜合性風險。
雖然極少會出現企業因技術債務而走向衰敗的案例，但新晉企業憑借新技術和商業模式顛覆傳統行業并奪取市場份額的報道卻不斷發生。 這從另一方面說明技術債務綜合提升了采用新技術的機會成本，使企業不斷失去創新和領先的巨大潛力。
DevOps 技術棧的多元化為分散遺留系統技術債務風險提供了一套靈活而又低風險的工具和方法論。不斷幫助企業從遺留系統的負擔中解脫出來。
而微服務則是首先通過領域拆分技術債，并用相應工具重組技術債。分離優質技術資產和不良資產，通過分散風險來降低拋棄成本。 而將API 當做產品(APIs as a product) 可以從一個全新的演進視角去看待技術債，通過可用性測試和用戶體驗研究幫企業剝離出技術債務中的優質資產和不良資產。
另一方面，本期技術雷達中出現了封裝遺留系統這樣的實踐，它往往配合著 Vagrant ， Packer 和 Docker 這樣的工具一起使用。一方面它將技術債務的風險進行了隔離，另一方面它防止了遺留系統上產生的技術債利息的增長。
趨勢6：安全成為推動 DevOps 全面發展的重要力量
安全是 DevOps 永遠繞不開的話題，也往往是新技術在傳統行業（例如金融和電信）應用中的最大阻礙。一方面，組織結構的轉型迫使企業要打破原先的部門墻，這意味著很多原先的控制流程不再適用。另一方面，由于大量的 DevOps 技術來源于開源社區，缺乏強大技術實力的企業在應用相關技術時不免會有所擔憂。
從代碼中解耦秘密信息的管理 則讓我們避開了一些開發過程中可能會產生的安全隱患。采用git-crypt這樣的工具可以幫我們保證在開發的過程中源代碼內部的信息安全。而采用HashiCorp Vault則提供了脫離應用程序代碼的秘密信息存儲機制，使得應用在運行過程中的秘密得到了有效保護。
Linux Security Module 則一直在技術雷達的“采用”區域，通過 SELinux 和 AppArmor 這樣的 LSM 兼容幫助團隊評估誰可以訪問共享主機上的哪些資源(包括其中 的服務)。這種保守的訪問管理方法將幫助團隊在其SDLC流程中建立更好的安全性。以往這是 Ops 團隊需要考慮的問題，而對 DevOps 的團隊來說，這是每一個人的事情。
“合規性即代碼”（Compliance as Code）是繼“基礎設施即代碼”，“流水線即代碼”之后的又一種自動化嘗試。InSpec作為合規性即代碼的提出者和實現者，通過自動化手段確保服務器在部署后的運維生命周期中依然保持安全與合規。它所帶來的意義在于將規范制度代碼化，得到了確定性的結果和解釋。
在不遠的將來，不難想象人們所面對的法律和法規規定不再是一堆會導致歧義的語言文字條目，而是一組由自動化測試構成的測試環境。
安全性和易用性往往被認為是魚與熊掌不可兼得的兩個方面。在 DevOps 之前，團隊吞吐量和系統穩定性指標曾經也面臨這樣的境遇，然而 DevOps 使得二者可以兼得。同樣我也有信心看到在未來 DevOps 的領域里，更多易用且安全的工具將會不斷出現。在降低 DevOps 所帶來的安全風險的同時，也提升團隊開發過程的順暢性和用戶便利性。
趨勢7：Windows Server 和 .NET平臺下的 DevOps 技術潛力巨大
長期以來，Windows 和 .NET平臺下的 DevOps 一直都是一個被低估的領域。一方面，社區缺乏對 Windows ?Server 平臺的興趣。另一方面，Windows Server 卻有接近 90% 的市場占用率，在 Web 服務器領域則有33.5% 的市場占有率。
有充足理由證明這是一個潛力巨大的市場。 我們看到了CAKE 和 FAKE這樣的條目，作為 .NET 平臺下替代 MSBuild 的構建解決方案， 它增強了 .NET 平臺自動化方面的能力。而HANGFIRE則提供了更易用和靈活的自動化進程調度框架。我很期待未來有更多 Windows Server 和 .NET 平臺 領域的創新。不久前，Docker 已經可以在 Windows 下運行。可以預見到，Windows Server 和 .NET 平臺將會是下一階段 DevOps 技術實踐中值得深入發掘的領域。
趨勢8：非功能性自動化測試工具的逐漸完備
自動化測試水平往往是衡量 DevOps 技術能力高低的重要指標，尤其是針對生產環境應用程序的非功能性自動化測試工具。一直以來，技術雷達都在嘗試從不同的角度宣揚自動化測試的重要性，從軟件的開發階段延展到了整個應用生命周期甚至整體 IT 資產的管理上。
這期的技術雷達仍然關注了非功能性自動化測試，TestInfra是 ServerSpec 的 Python 實現，它使得用Pytest測試基礎設施成為可能。而MOLECULE旨在幫助開發和測試 Ansible 的 Role 。通過 在虛擬機或容器上為正在運行的 Ansible Role 測試構建腳手架，無需再手工創建這些測試環境。 正如技術雷達所說的：“雖然這是一個相當年輕的項目，但我們看到了其蘊含的巨大潛力。”
趨勢9：Python 成為 DevOps 工作中采用的首要編程語言
早在 DevOps 剛剛開始盛行的時候，Python 就是一個被寄予厚望的語言，因為大部分 DevOps 工具和實踐都需要用到 Python。雖然也有人嘗試用 Ruby 或者 NodeJS 構建 DevOps 工具，然而都沒有 Python 所構建的工具流行。與此同時，仍然不斷有人把其它語言下編寫的工具轉化為 Python 的版本，TestInfra 就是這樣一個例子。
隨著 Python 在大數據、人工智能、區塊鏈、微服務以及 Docker 中的發展，可以預見 Python 在日后的領域仍然會發揮重要的作用。
以上對 DevOps 趨勢的解讀僅為個人觀點，如有不當之處還望指出，關于更多技術在技術 雷達中的使用建議請參考https://www.thoughtworks.com/radar/a-z。謝謝。
