今年4月份，我第一次以主編的身份參加技術雷達的翻譯工作。有幸第一時間參加到技術雷達的翻譯過程中。通過我在翻譯其間對條目的了解和觀察，我寫下了《DevOps發展的九個趨勢》
今年11月份，我再一次以執行主編的身份參加第17期技術雷達的翻譯工作。17 期技術雷達中兩大主題：Kubernetes 和 Cloud as the New Normal 都是 DevOps 相關的。而且本期技術雷達涌現了眾多 DevOps 相關的新條目。一方面說明了 DevOps 在 IT 業的重要性日漸增加，一方面也支撐起了 DevOps 社區在工具和實踐上的創新。雖然每個人對 DevOps 的理解不盡相同，但能持續的著眼在具體的問題并提供實際的解決方案則是值得稱道的。
這些新的變化對我上一期的 DevOps 技術趨勢判斷和發展有了新的思考和認識，借由此文分享給大家。
回顧2017年 DevOps 發展
在今年 4月第16期技術雷達發布后，我分析了 DevOps 發展的九個趨勢。我認為這九個趨勢代表了2017年 DevOps 技術的發展方向。讓我們來結合最新的技術雷達回顧一下2017年這些趨勢的發展。
趨勢1：微服務目前仍然是DevOps技術應用和發展的主要領域
現狀：微服務的相關技術仍然不斷涌現。但人們似乎過于樂觀的估計了微服務的投資回報速度。架構演進是一個長期的過程，而實踐中的陷阱和問題越來越多。不斷涌現的諸多工具和解決方案說明了微服務的反思已經開始。讓我們期待更多微服務的案例出現。
趨勢2：以Docker為核心的數據中心方案逐漸走向成熟
現狀：Kubernetes 生態圈在 Docker 編排工具的爭霸大戰中笑道了最后，本期技術雷達把 Kubernetes 移動到了“采用”中，證明 Kubernetes 是經得住時間考驗的工具。隨著越來越多的廠商和社區開始圍繞 Kubernetes 構建自己的產品，我相信基于 Kubernetes 的產品和工具會越來越多。
趨勢3：不完整的DevOps實踐阻礙著DevOps的發展
現狀：雖然 DevOps 社區的活躍程度催生了一大批的工具和平臺，但卻在推廣實踐上發力不足。接受了局部技術改進后的 DevOps 演進似乎立刻停止，使得 DevOps 難以發揮出更大的價值。隨著時間的發展，這種局面會愈來愈常見。如 方法論的推廣落后于工具的發展，那么 DevOps 運動的壽終正寢也將為期不遠。
趨勢4：領域特定的DevOps實踐開始出現
現狀：雖然并沒有十分特別的領域特定的 DevOps 技術出現。但受到 DevOps 啟發的 DesignOps 和 DevSecOps 也分別有了自己的社區群體。期待它們在未來有進一步的表現。
趨勢5：采用DevOps進行技術債務重組和技術資產管理
結果：我寫下這個趨勢的第二周就進入了這樣一個技術資產管理項目并工作到現在。在這 6 個月中我和同事們采用了 DevOps 理念和技術進行技術資產重組和互聯網企業 IT 資產并購，并體會到了其中的諸多益處，大大節約了產品上線時間和上線風險，而且產品的開支的隨著時間以更快的速度遞減。隨著 CloudNative 的技術和概念的成熟，相信這類的項目和案例會越來越豐富。
趨勢6：安全成為推動DevOps全面發展的重要力量
結果：OWASP Top10 和 OWASP Top10 Mobile 的姍姍來遲雖然并未進入本期技術雷達。但并不表明技術雷達對安全有所松懈，這反而是一種更加負責的態度。而安全相關的實踐已從使用工?具進入安全場景的設計。例如最新期的 3Rs 安全 和 上一期就提到的 KeyCloak，以及本期提到的用于安全的 Sidecar 模式。
趨勢7：Windows Server和.NET平臺下的DevOps技術潛力巨大
現狀：隨著 Azrue 的成熟 和 Windows Conatiners 的推出，Windows 領域的 DevOps 關鍵工具鏈即將打通。但是 MS-DevOps 的“最后一公里”顯得比較艱難。MS-DevOps 的社區的發展并不活躍，使得 Windows Server 的相關實踐略顯不足，這進一步限制了 DevOps 相關技術在 Windows 平臺上的作為。
趨勢8：非功能性自動化測試工具的逐漸完備
現狀：更多的工具開始圍繞“自動化測試”展開，關于自動化測試為開發帶來的諸多益處以無需多言。在本期技術雷達里我們看到了更多這樣的技術出現，例如：TDD in Containers，Flood.io 用于負載測試，Heptio Sonobuoy 用于合規測試。而一個成熟穩健的架構，必須要經得起來自各方面的測試。
趨勢9：Python成為DevOps工作中所不可或缺的語言
現狀：Python 仍然重要，但 Go 語言在 Ops 相關工具中的地位也在逐步提升。
2018 年的 DevOps 技術的發展趨勢
雖然條目眾多，但我們可以從技術雷達中整理出 4 個 DevOps 發展脈絡：
趨勢1：微服務的實踐進入深水區
微服務在部分企業的成功給所有的企業描述了一個美好的愿景，但通往這條美好之路的路程則并不那么一帆風順。
微服務是成功的結果，而非成功的原因，我把成功的架構轉型經驗的結果架構稱之為微服務架構。但這并不是微服務成功的動因，畢竟這些最初成功應用微服務企業最開始的時候并沒有“微服務”的概念。而能夠讓微服務成功一定是在特定場景下遵守了某些重要的原則。而這些特定的場景和原則似乎被人忽視，而只能從表象上描述這一成功的結果。
隨著微服務在各種場景下的應用，針對不同行業，不同組織，不同技術上下文的實踐被慢慢總結出來。有些是成功經驗，有些則是反思。例如: Service Mesh （服務嚙合）和 Overambitious API gateways（過度龐大的API網關產品）就是相互關聯的技術。而 KONG API Gateway 就是一個十分不錯的 API 網關工具，但結合了不同的上下文，可以得到不同的結果。
成功微服務實踐者一直在強調康威定理的重要性，而現實中的企業往往忽視條經驗。同樣的技術和工具，在不同的業務上下文和組織結構里，就會得出不同的結果。Kafka 的使用并不能表示你正在往正確的路上走，僅僅替換了工具而非思維和架構模式會將你帶入 Recreating ESB antipatterns with Kafka（用 Kafka 重建 ESB 反模式）。所以，采用某些技術或工具一定要識別對正確的場景。
?另一方面，成功的經驗和重復被證明成功的微服務實踐則作為框架被流傳了下來。Spring Cloud 作為 微服務解決方案的杰出代表繼續在技術雷達中擁有自己的一席之地，以至于現在任何一本關于微服務的書都是以 Spring Cloud 展開的。此外，技術雷達里有增添了 Spring Cloud 的新成員：Spring Cloud Contract 是和 Spring 框架結合緊密的消費者驅動契約測試的工具。這說明消費者驅動的契約測試被證明是有效的微服務測試方法。盡管技術雷達第一次提出消費者驅動的契約測試已經過去了3年。
當微服務的架構轉型到了深水區，微服務的標準實踐架構即將出現，一掃微服務生態圈的混亂情況。就如曾經發生在 Docker 社區中的一樣。
趨勢2：如果你正在使用 Docker，請向 Kubernetes 遷移
技術雷達一直保持著對 Docker 社區的關注度，因為這是我們普遍采用的技術。但在大規模的使用上面，技術雷達則相對保守，盡管技術雷達從 2015 年就開始關注 Kubernetes ，但直到這次才放到“采用”區域里，證明了 Kubernetes 已經非常成熟。圍繞著 Kubernetes 生態工具鏈也逐漸完善，無論是廠商（Google 的 GKE 解決方案，還是 AWS 的 EKS）提供的完整平臺。還是社區的 Kops 和 Sonobuoy 這樣的，都不斷在增強 Kubernetes 在生產環境的實際應用能力。
如果你之前也在觀望容器大戰，現在可以果斷進入 Kubernetes 了，如果你準備在生產環境使用 Docker，請優先考慮 Kubernetes。如果你已經用了 Kubernetes，那么恭喜你！希望你能將你的杰出實踐經驗分享給大家。
趨勢3：Cloud Native DevOps
云計算技術不光極大降低了 IT 運營成本，更改變了開發和運維的工作方式。DevOps 在企業級的應用遇到的更多阻力在云端，無論是應用架構還是工作方式。
很多企業仍然僅僅把云平臺當做一個 “遠程托管機房”，并沒有發揮出云平臺組件和 SDK 帶來的組合性優勢。
CloudNative 最大的思維轉變當屬 Stateless Infrastructure（無狀態基礎設施）。這樣可以大幅度保障應用的可用性和水平擴展能力，當傳統的計算資源和存儲資源已經通過云計算技術達到了海量。應用的瓶頸就來自于應用架構和基礎設施結構。如果還在思考基礎設施的狀態如何監控和保存，就又進入了老的思維模式，只不過換了新的工具而已。
Serverless Framework 和 Apex 框架就是采用 CloudNative 思維的代表，在實際的應用中它顛覆了我們對軟件開發和運維的很多認識。把基礎設施當做一個資源相對無限的狀態機，你的應用就是這個狀態機的狀態配置，并通過版本化的手段在線保存狀態。把對基礎設施和設備的依賴降低到最小：只需要一個代碼庫。
而在這樣的情形下，我們不需要構建一套開發環境和測試環境（你并不想只十幾行代碼就需要搭建一套虛擬的云計算環境）。而全部都在生產環境上工作，只不過生產環境有高級別的隔離，且各部分狀態不同，有的是在生產狀態，有的是在開發測試狀態。
此外，更多的開發基礎設施和測試工具以平臺的形式也相繼推出，它們不光提升了安全性和穩定性，更降低了企業 IT 資產總和管理成本。例如：CircleCI 和 BuildKite 就是持續集成服務器的平臺化實現，只需要在代碼里有很少的配置就可以解決搭建整套持續交付流水線的各種繁瑣步驟和功能。Flood.io 則是通過在云端模擬大量的用戶訪問請求進行負載測試，這不光有助于你發現自己的基礎設施和應用的瓶頸，更能幫你預演在高流量的狀況下整個團隊的響應能力。
由于眾所周知的原因，我們無法訪問本期技術雷達提到的 GCP（Google Cloud Platform），有限的使用 AWS 和 Azure，但仍然無法阻擋云計算的發展迅猛之勢。
當云計算平臺提供了一系列廉價而又靈活的基礎設施之后。實踐 DevOps 的你需要思考如何把傳統的實踐推向極致。
趨勢4：自動化，更多的自動化！
自動化永遠是 DevOps 的核心主題之一，各種自動化測試工具和平臺的興起似乎在說明我們以往的自動化測試是不夠的。新的自動化測試工具和方法正在越來越多。本期我們看到了關于 TDD in Containers 和 Sonobuoy，分別是，由于新版本 Chrome 的 Headless 模式的發布，未來的自動化測試則會越來越多，越來越完整。
我們可以把基礎設施想象成一個軟件產品，通過基礎設施流水線構建這樣的產品。我們甚至可以使用 基礎設施流水線把生產環境的更新做到極致：每天進行生產環境的從頭構建，自動化配置網絡以及基礎設施，自動化還原數據庫備份，每天產生一個可用的架構。這樣的生產環境上就會有兩個架構：一個生產中，一個待生產。你不在需要開發環境和測試環境，每天的工作都保存在待生產的架構上。由于第二天就要發布，因此今天會把所有的工作控制在明天發布之前完畢，而且要符合生產要求。這樣就可以迫使團隊把自己的工作自動化并且提升交付質量。也避免在自己的電腦上或者某個代碼分支上存儲很久。
數據中心的災后重建就是極為痛苦的事情，因此需要做災備預演。而現有的階段性災難預演已經無法滿足要求。所以對于云端的基礎設施來說，有災難要預演，沒有災難要制造災難預演。這樣可以使你基礎設施和應用架構達到極端的可用性和可恢復性，同時實現了 3Rs? 安全。就像《持續交付》一書中所說的：經常做那些讓你感到痛苦的事情。由于 AWS 提供了 VPC 級別的隔離，我已經可以通過 CloudFormation + Ansible 做到這一點，未來會把相關經驗分享給大家。
另一方面，我們看到了 基于算法的IT運維（Algorithmic IT Operations），甚至提出了 AIOps 的概念。但基于算法的運維仍處在初步階段。雖然我很樂于看見新的技術發展趨勢，但每個領域的 AI 熱潮是掩蓋了真正的問題，還是讓我們更快的找到了問題的正確答案？還有待觀察。
最后
17 期的技術雷達的關注重點在 DevOps 上。一方面說明企業級應用正在全面的向云遷移，另一方面也說明云平臺上的技術發展也在同樣進步。在這個過程中我們遇到了新的問題，同時也遇到了新的機遇。當前這一系列的 DevOps 技術的浪潮會帶來什么樣的發展，明年的技術雷達將會揭曉。
