作者丨孫健波（天元） 阿裡巴巴技術專家
導讀：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 會消失嗎？
近幾年，Kubernetes 項目經常被描述成 DevOps 的“最佳拍檔”。類似的觀點認為， Kubernetes 跟 Docker 一樣，解決的是軟體運作時的問題。這意味着 Kubernetes 更像一種“時髦”的 IaaS，隻不過運作時從虛拟機變成了容器。是以，隻要能夠将現有 DevOps 思想和流程對接到 Kubernetes 上來，就可以享受到容器技術帶來的輕量級與彈性。這對于提倡“靈活”的 DevOps 來說，顯然是最好的組合。
不過，至少目前看來，Kubernetes 的發展路徑并不是一個類 IaaS 的角色。它雖然關注接入底層的基礎設施能力，但它本身卻又不是基礎設施能力的提供方。而且，相比于軟體運作時，Kubernetes 似乎更關心軟體的生命周期和狀态流轉。不僅如此，它還提供了一種叫做“控制器模型”的機制來将軟體的實際狀态與期望狀态不斷逼近，這顯然都已經超出了一個“軟體運作時”的範疇。
Kubernetes 項目對應用本身的“額外關注”，讓它與一個類 IaaS 基礎設施有着明顯的差別，也讓它“膠水”的定位更加明顯。而如果 Kubernetes 的能力足夠強大，那麼作為研發與基礎設施之間現有的“膠水層”， DevOps 是否還有必要存在？在所謂的雲原生時代，應用研發與傳遞是不是真的會走向“一次聲明”就可以“撒手不管”，進而讓 DevOps 徹底消失呢？
不過，至少目前看來，Kubernetes 項目距離這個願景，還有不少困難需要克服。
“Platform for Platform” API 的局限性
Kubernetes 是一個典型的 “Platform for Platform”項目，是以它的 API，距離純研發視角還是非常遙遠的。就比如一個 Deployment 對象，就既包括了研發側關心的鏡像，也包括了基礎設施側的資源配置，甚至是容器安全配置。此外， Kubernetes API 并沒有提供出對“運維能力”的描述與定義方式，這也使得聲明之後的“撒手不管”變得遙不可及。這也是為什麼目前 DevOps 依然被需要的原因：Kubernetes 的大多數字段，還是必須經過研發和運維共同協作的流程來進行填充。
無法對更多的雲資源進行描述
K8s的原生API隻包含了雲資源的很少一部分，比如用 PV/PVC 表達存儲，用 Ingress 表達負載均衡，但這對于一個完全聲明式的應用描述來說是完全不夠的。比如，研發希望在K8s上找到一個概念來表達資料庫、VPC、消息隊列等需求的時候，就會感到非常困惑。而現有的所有方案則完全依賴于雲廠商的實作進而帶來了新的 vendor lock-in 困惑。
Operator 體系缺乏互操作性
Kubernetes 的 Operator 機制是這個項目的能力能夠無限增長的公開秘密。但令人遺憾的是，目前所有 Operator 之間的關系，就像是一個又一個的煙囪，互相之間沒有任何互動與協作的可能。比如，我們把雲上的 RDS 通過 CRD 和 Operator 擴充到了 K8s 聲明式API的體系中，但是當第三方希望寫一個定時備份 RDS 持久化檔案的 CRD Operator去配合的時候，卻往往無從下手。這就又需要 DevOps 的體系介入來解決問題。
未來？
顯然，現在的 Kubernetes 項目，依然需要借助 DevOps 體系來真正完成軟體的高效疊代與傳遞工作。這是不可避免的：盡管 Kubernetes 聲稱自己是“以應用為中心”的基礎設施，但它作為一個從 Google Borg 衍生出來的系統級項目，其本身的設計和工作層次還是更多的基礎設施領域徘徊。但另一方面，我們絕不可否認的是，Kubernetes 在它的關鍵路徑上，始終保持着對研發側 “NoOps” 的追求。這種渴望，從它第一天提出“聲明式應用管理”理論的時候就已經“昭然若揭”，而 CRD 和 Operator 體系的建立，更讓這種應用級别的關心終于有了落地的機會。我們已經看到很多 DevOps 流程正在“下沉”為 Kubernetes 裡的聲明式對象與控制循環，比如 Tekton CD 項目。
如果 Kubernetes 的未來是 100% 的聲明式應用管理，那麼我們有理由相信 DevOps 最終會從技術領域消失然後徹底蛻變成一種文化。畢竟，那個時候的運維工程師，可能都會成為 Kubernetes Controller/Operator 的編寫者或者設計者。而研發呢？他們可能根本不會知道原來 Kubernetes 這個東西曾經如此顯赫的存在過。
OAM
在 2019 年 10 月，阿裡雲聯合微軟一起釋出了開放應用模型 Open Application Model(OAM)，打破了傳統的軟體傳遞模式，OAM 是專注于描述應用生命周期的标準規範，可以幫助應用開發者、應用運維人員和基礎架構運維團隊更好地進行協同。
目前，OAM 還處于一個早期階段，阿裡巴巴團隊正在上遊貢獻和維護這套技術，如果大家有什麼問題或者回報，也非常歡迎與我們在上遊或者釘釘聯系。
參與方式：
- 釘釘掃碼進入 OAM 項目中文讨論群
- 通過 Gitter 直接參與讨論
- OAM 開源實作位址（star 一下！）
期待大家的參與！
雲原生技術公開課
本課程是由 CNCF 官方與阿裡巴巴強強聯合，共同推出的以“雲原生技術體系”為核心、以“技術解讀”和“實踐落地”并重的系列[技術公開課](https://edu.aliyun.com/roadmap/cloudnative)。
“阿裡巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”