DevOps和它的朋友們——聊聊其他“Ops”(二)
上篇跟大家簡單介紹了DevOps,以及與其概念相近的NoOps、DevSecOps和GitOps,“Ops家族”還包含其他形式,但歸根結底,DevOps之所以更為流行,是因為其提供了改進工作流程的最全面的方法,因而被廣泛應用。
DevOps vs. ITOps
接下來,我們將更仔細地瞭解一下ITOps。許多開發人員將ITOps視為DevOps更傳統的版本,但實際上它不止於此。ITOps在許多方面與DevOps非常相似。該方法將軟體開發和IT基礎設施管理視為一個統一的管道,此外,它還試圖改進該管道並推動更高的靈活性。
ITOps與DevOps的不同之處在於它如何管理IT基礎設施。這正是ITOps更為傳統的地方,因為它負責交付和維護服務、應用程式,以及運維業務所必需的基礎技術。ITOps通常包括系統管理員、網路管理員和服務檯等職位。
ITOps更關注穩定性和長期可靠性,而不是推崇敏捷性和速度。IT基礎設施是作為成功管道的基礎處理的,因此,當涉及到基礎設施管理時,看到這種方法被視為更加嚴格就不足為奇了。
ITOps的最佳實踐更傾向於使用可靠的、經過高度測試的商業軟體和解決方案來構建基礎設施——包括硬體,因為ITOps傾向於關注物理伺服器和網路。ITOps的管道中經常有現成的商用軟體或COTS。
這種方法的更高剛性也意味著更新基礎設施元件更加困難。ITOps將穩定性作為首要任務,因此快速更改雲和內部環境的配置並不總是可能的。不過,ITOps在應用程式和服務的內部部署方面確實工作得很好。
這並不意味著ITOps已經過時。有些行業嚴重依賴ITOps的長期可持續性,比如銀行業和整個金融業。這些行業並不總是需要快速、突然的變化,這使得ITOps成為更合乎邏輯的持續交付方法。
人們可能會認為DevOps無法在這些型別的環境中實現,因為它們不是基於雲的。但事實並非如此,在裸金屬伺服器上仍然可以減少在製品數量和降低貯倉量。
DevOps vs. CloudOps
當ITOps將基礎設施轉移到等式更傳統的一邊時,CloudOps卻恰恰相反。同樣,這種方法與DevOps非常相似,但是在基礎設施管理方面的關注點有所轉移。顧名思義,CloudOps試圖更多地利用現代服務提供商(如Amazon)提供的雲原生功能。
CloudOps主要有三個要素:分佈、無狀態和可伸縮性。分散式開發和部署意味著不存在單點故障。整個雲環境變得更加可靠,並且可以保持正常執行時間。同時,至少在工作流的某些部分,無狀態化的能力對於成本效率來說是一個巨大的優勢。
由於是無狀態的,所以可伸縮性不是問題。您只需要為實際使用的資源和使用它們的持續時間付費,因此,只需稍加調整,就可以將與雲相關的開銷成本降至最低。使用CloudOps方法部署的雲本地應用程式往往具有良好的正常執行時間和低延遲。
雲服務提供商現在提供的自動化水平進一步擴大了這些優勢。然而,這種方法需要完全自動化的資源配置,這可能意味著在配置CI/CD管道時增加了複雜性。為了充分利用CloudOps,必須正確配置才能充分利用CloudOps的優勢。
DevOps vs. CIOps
持續整合操作(CIOps)是我們列表中的最後一個分支。CIOps要求CI操作員或管理員在繼續部署之前配置支援新程式碼所需的IT基礎設施。CI系統被設計用來執行構建和測試,然後根據管道的複雜性以不同的複雜級別部署。
由於手工輸入仍然是必需的(為了確保每個CI作業都被正確配置以部署到正確的位置),CIOps既有優點也有缺點。主要優點是對基礎設施本身進行細粒度控制。與GitOps等方法中預定義的引數不同,兩種部署可以有不同的基礎設施配置。
手工配置雲環境和資源配置可以使CIOps更適合較小的開發;在開發專案中,自動化是一種麻煩而不是一種有用的工具。這就是CIOps經常出現在具有更簡單雲基礎設施的小型專案中的原因。
手工配置雲環境和資源配置可以使CIOps更適合較小的開發;在開發專案中,自動化是一種麻煩而不是一種有用的工具。這就是CIOps經常出現在具有更簡單雲基礎設施的小型專案中的原因。
然而,這裡的主要缺點是這個系統的人工概念增加了人為錯誤的風險。還需要為API提供您選擇的CI工具(Travis CI和CircleCI很流行),這是一個很大的安全風險。
與DevOps相比,CIOps還缺乏全面的審計跟蹤和額外的靈活性。該方法關注的是CI而不是CI/CD,因此它並不總是涵蓋整個過程。雖然它在配置雲基礎設施時給了開發人員一些靈活性,但要在較長的時間內平穩地執行CIOps,還需要大量的努力。
為什麼是DevOps ?
正如您所看到的,DevOps有多個分支和子集,它們都基於獨特的方法和有趣的想法。為了加快您的CI/CD週期,所討論的任何方法都非常有用。在兩者之間進行選擇,就是要找到一種最適合您開發的應用程式和您使用的雲基礎設施的方法。
也就是說,DevOps仍然提供了改進工作流程的最全面的方法,因為它在採用文化改進的同時處理了兩個技術過程。兩者在成功轉型中同等重要。上述方法往往只關注技術方面,有些甚至專注於特定的平臺、管理基礎設施的方法或特定的工具。
歸根結底,這就是為什麼DevOps仍然是所有方法中實現最廣泛的原因。這是一種久經考驗的方法,可以在支援創新和協作環境的同時,建立一個高效且在技術上得到改進的CI/CD管道。
相關文章
- DevOps和它的朋友們——聊聊其他 “Ops”(一)dev
- InhertedWidget和它的繼承者們繼承
- 一文搞懂DevOps、DataOps、MLOps、AIOps:所有“Ops”的比較devAI
- 如何鑑別“偽二次元”?二次元遊戲和它的玩家們二次元遊戲
- ES6中的class物件和它的家人們物件
- 那些“一個人做的遊戲” 和它的玩家們遊戲
- 我的機器人朋友們機器人
- python2的朋友們注意!!!Python
- 在Linux中,RAID級別和它們的用途是什麼?LinuxAI
- 我們們聊聊艙壁模式模式
- 我們自研的那些Devops工具dev
- 簡單聊聊運維監控的其他用途運維
- 再聊我們自研的那些Devops工具dev
- 我們來聊聊命名
- oracle opsOracle
- 聊聊關於效能優化和其他(一)優化
- 火焰之紋章系列編年史:“火焰紋章”和它的製作人們
- 程式設計師們,你們再這樣下去會沒朋友的程式設計師
- 我們們一起聊聊Java異常Java
- 我們們來聊聊併發工具類Semaphore
- 我們們來聊聊正向代理和反向代理
- 我們們聊聊如何搭建開發環境?開發環境
- 六宮粉黛盡作灰:一款“昏君模擬器”和它的玩家們
- DevOps是什麼?DevOps能夠給我們帶來什麼?dev
- 聊聊二維碼
- 讓我們來聊聊前端的工程化前端
- Linux是啥?我們來聊聊?Linux
- 解鎖Java面試中的鎖:深入瞭解不同型別的鎖和它們的用途Java面試型別
- AI、聲效、震動:聊聊動作遊戲的其他設計AI遊戲
- JavaScript和它父親的故事JavaScript
- 2024年釋出的多模態大語言模型和它們採用的設計方法模型
- 我們們聊聊對賬系統該如何設計
- 為 PHP 轉 Go 的朋友們推薦一款神器PHPGo
- 我們來聊聊Cookie、Session和Storage的那些事CookieSession
- 搭建fast-whisper 環境時報錯 Unable to load any of {libcudnn_ops.so.9.1.0, libcudnn_ops.so.9.1, libcudnn_ops.so.9, libcudnn_ops.so}ASTDNN
- 泡杯茶,我們坐下聊聊Javascript事件環JavaScript事件
- 扯淡的DevOps,我們開發根本不想做運維!dev運維
- 雲棲收官:想跟遠道而來的朋友們說