點擊底部瞭解更多，查看[DevOps是否會消失及未來變革]
DevOps 這個概念最早是在 2007 年提出的，那時雲計算基礎設施的概念也才剛剛提出沒多久，而隨著互聯網的逐漸普及，應用軟件的需求爆發式增長，軟件開發的理念也逐漸從瀑布模型（waterfall）轉向敏捷開發（agile）。傳統的軟件交付模式（應用開發人員專注於軟件開發、IT 運維人員負責將軟件部署到服務器運行），再也無法滿足互聯網軟件快速迭代的需求。於是，DevOps 作為一種打破研發和運維之間隔閡、加快軟件交付流程、提高軟件交付質量的文化理念和最佳實踐 逐漸普及至今。
DevOps 的現狀
DevOps 的流行得益於業界對於應用軟件敏捷開發、高質量交付的訴求，所以為開發和運維開闢了一塊“公共的空間”，讓雙方可以在這裡緊密合作。那時軟件研發依舊屬於一個新興行業，人們習慣於向成熟的製造業學習，製造業解決大規模生產的方式，就是構建流水線，通過流水線規範化每個步驟對接的內容，而流水線上的工人們則只需要各司其職，快速熟練的完成自己這部分生產內容。
所以，DevOps 借鑑了製造業的經驗，開始構建持續集成 / 持續交付（CI/CD）的流水線，催生出了一系列自動化 / 半自動化工具（如 puppet、chef、ansible 等），結合編寫腳本的可擴展能力，將研發和運維的大量操作規範化，從而達到彼此協作的目標。但是最終還是要有人投入到這些工具的構建中，於是就出現了 DevOps 團隊。DevOps 團隊構建的工具和平臺，幫助研發更容易地接近生產環境，讓研發在持續集成、持續交付的過程中可以一鍵部署、快速試錯，從而很大程度提前暴露和避免了軟件在實際運行過程中的問題。
從本質上講，DevOps 是為運維服務的。 它把生產環境的運維流程通過自動化的工具提供出來了，屏蔽了基礎設施細節，同時讓軟件本身的問題更容易暴露，從而把這些問題儘量提前交給研發去解決。這些，其實都是在幫助運維減輕負擔。
這一套模式在一開始運轉良好，但是問題也隨著時間的推移慢慢暴露出來了。DevOps 本身不為企業帶來直接的利潤，也不增加產品的功能，它們是企業的成本中心，所以許多企業不願意為 DevOps 投入太多的成本。久而久之，DevOps 的能力便無法與研發人員增長的需求所匹配，不願意繼續伴隨著雲和開源社區的發展向前演進，反而成為軟件研發的瓶頸。試想一下，有多少大公司的技術人員，對自己公司裡的“研發效能”工具表示滿意呢？
雲計算的普及
聰明的企業總能從自己的需求中發現業界共有的需求，AWS 便是這麼誕生的，他們早在 2006 年便首次把軟件部署需要的網絡、計算、存儲等基礎設施當做服務提供給用戶，允許任何人在不購買服務器等物理硬件的情況下構建互聯網應用程序，規模化使得整體的成本比用戶自建更低。而云計算 IaaS、PaaS、SaaS 的概念也正是在那一年開始逐漸清晰的。
雲計算的初期，用戶主要使用的是 IaaS 服務，如虛擬機、存儲等，使用雲計算服務的企業依舊需要運維來管理這一類基礎設施，只是運維管理的對象從物理機切換到虛擬機而已，並沒有太本質的區別。
而隨著雲計算的快速發展，雲的能力不斷補充、增強，漸漸將原先由運維提供的方方面面的能力都轉換成為了雲上的服務，這其中自然包含了管理軟件完整生命週期的各類服務，從代碼託管、持續集成、持續交付，到監控、報警、自動擴縮容等一系列的能力，均能在雲上找到對應的服務。品類之多、數量之巨，令人瞠目結舌。
但是 DevOps 依然有著用武之地。雲的對接難度實在太大了，涉及到的雲服務又多，不同雲廠商提供的服務還不統一，為了使用雲上的產品不得不投入大量的時間學習，而為了防止雲廠商的綁定又不得不做多廠商的適配，DevOps 依舊需要像過去一樣為開發屏蔽實際環境的複雜性，只不過這次他們要負責管理的基礎設施變成了雲資源。
改變一切的 Kubernetes
Kubernetes 的本質是現代應用基礎設施，它關注如何將應用與“雲”天然地集成在一起，將“雲”的最大價值發揮出來。Kubernetes 強調讓基礎設施能更好的配合應用、以更高效的方式為應用“輸送”基礎設施能力，而不是反之。在這個過程中，Kubernetes 、Docker、Operator 等在雲原生生態中起到了關鍵作用的開源項目，正在在把應用管理與交付推上一個跟以前完全不一樣的境況：Kubernetes 的使用者只通過聲明式的方式描述自己應用的終態是什麼，然後一切就結束了。Kubernetes 會處理後面的所有事情。
這也是為什麼 Kubernetes 非常強調聲明式 API。通過這種方式，Kubernetes 本身接入的基礎設施能力越強，Kubernetes 的使用者能夠聲明的終態就越豐富，他的職責也就越單純。現在，我們不僅能夠通過 Kubernetes 聲明應用的運行終態，比如；“這個應用需要 10 個實例”，我們還能夠聲明應用的很多運維終態，比如：“這個應用使用金絲雀發佈策略進行升級”，以及 “當它的 CPU 使用量大於 50% 時，請自動擴展 2 個實例出來”。
這就是傳統的 DevOps 工具和團隊受到了挑戰：如果一個業務研發自己只需要通過聲明式 API 聲明他的應用的所有終態甚至包括完整的 SLA，後面的一切就都會有 Kubernetes 來自動的搞定，那麼他還有什麼理由去對接和學習各式各樣的 DevOps 流水線呢？
換句話說，長久以來，DevOps 實際上是在充當研發與基礎設施之間的那一層“膠水”。而現在，Kubernetes 通過它極具生命力的聲明式 API 和無限接入的應用基礎設施能力，正在完美的扮演這個“膠水層”的作用。這也提醒了我們，上一個正在被 Kubernetes 體系強烈挑戰的“膠水層”，其實叫做“傳統中間件”：它正遭受到 Service Mesh 的巨大沖擊。
DevOps 會消失嗎？
關鍵字：DevOps Kubernetes 雲原生
閱讀更多 有隻黑白貓 的文章
