DevOps發展的9個趨勢 不完整的實踐阻礙DevOps的發展
DevOps包含了太多方面的技術和實踐，很難通過一個統一的工具鏈來描述其發展。即便如此，我們仍然可以看出一些趨勢。今年，我有幸作為主編參與了***一期技術雷達的譯制，作為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技術實踐中值得深入發掘的領域。
(圖片來自：http://t.cn/RX3hWed)
趨勢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在日后的領域仍然會發揮重要的作用。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
