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實踐。
趨勢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趨勢的解讀僅為個人觀點，如有不當之處還望指出。關於更多技術在技術雷達中的使用建議請參考這裡，謝謝。