“誰構建,誰運行”
在DevOps席卷全球的時代
有人卻對這一理念
提出了質疑
根據(jù)外媒記者Scott Carey的觀察報告,一眾開發(fā)者認為DevOps正在加重他們的負擔,大多數(shù)開發(fā)者并不想負責運維。一時間,“DevOps已死”的論調再度出現(xiàn)。
隨著數(shù)字化轉型浪潮的推進,企業(yè)需要更加靈敏、更加快速的運營,DevOps的出現(xiàn)徹底改變了軟件開發(fā)的模式,它為企業(yè)帶來了實實在在的好處,例如縮短響應時間、減少技術債務、消除脆弱性,它的價值也賦予了它極強的生命力。
Dev+Ops?
什么是DevOps的本質
如果你打開百度百科你就會發(fā)現(xiàn)DevOps是Development和Operations的組合詞,為了按時交付產品,開發(fā)和運維必須保持緊密的合作,但它的內涵絕不只是將開發(fā)和運維結合那么簡單。
在DevOps發(fā)展的十來年里,精益和敏捷貫徹其中,準確的說是“敏捷軟件開發(fā)”與“精益生產思想”的融合與演變,它可以是利用軟件工程的思維去解決繁雜的運維問題,也可以是通過自動化的流程消除開發(fā)、測試與運維之間的障礙。
盡管DevOps沒有一個明確的定義,但我們仍然可以發(fā)現(xiàn),它本質上是解決人、工具、人與工具之間的協(xié)作問題,以自動化的流程更好、更快的創(chuàng)造更高質量的軟件,從而幫助研發(fā)團隊獲得更好的交付價值。
壓力與負擔
DevOps的“不完全體”
DevOps無疑是好的,當開發(fā)與運維打破以往孤立的工作環(huán)境便能夠帶來1+1>2的效應。然而有些企業(yè)或組織將其理解成了“讓開發(fā)人員負責運維工作”,畢竟“誰開發(fā),誰運行”聽起來就像是這樣。如此一來,DevOps只有Dev沒有Ops,Dev就變成了全棧工程師。
全棧工程師自然也是好的,誰能拒絕一個全能的超人呢?但事實是,并非所有企業(yè)都有IT巨頭那樣的人才資源,都有足夠的時間和成本去培養(yǎng)一位全棧工程師。因此,在這些組織中,缺乏經驗的團隊在嘗試進行DevOps時往往會陷入混亂,導致開發(fā)人員與運維人員的職責、工作量以及壓力成倍增加。
根據(jù)媒體的報道,DevOps工程師們需要同時了解開發(fā)和運維的相關知識,缺乏標準化和自動化讓開發(fā)者運維時受到了許多限制,一些瑣碎的事情讓其無法全身心的投入到開發(fā)工作中,例如編寫格式嚴苛的Kubernetes配置文件;而運維人員除了要確保程序可用、安全、合規(guī)以外,還要負責構建和維護軟件交付通道。
平臺工程
DevOps的出路
為了消除這一負面影響,許多企業(yè)開始通過建立平臺工程或者內部開發(fā)平臺來緩解DevOps工程師們的壓力。
平臺工程以產品化的思維構建和維護可以在整個組織中大量復用的自動化平臺,開發(fā)者則是該平臺的“用戶”,內部開發(fā)平臺由大量 API、工具、服務、知識和支持構成,涵蓋了應用程序整個生命周期的運維需求,開發(fā)者無需明確協(xié)調即可“自助”使用該平臺,有效的消除開發(fā)與運維與產品之間的障礙。
平臺工程是否會取代DevOps我們無從得知,但小編認為,平臺工程并不是DevOps的替代方案,而是DevOps發(fā)展過程中進步的一種方式,因為它仍然是處理人與人、人與工具、工具與工具之間的關系,本質并未改變,只是融合的方式由“個性”轉向了“共性”。
Platform or DevOps
制定戰(zhàn)略才是首要任務
無論是平臺工程還是DevOps,轉型從來不是一朝一夕能夠完成的,在缺乏足夠戰(zhàn)略支撐的情況下,誰能保證平臺工程會不會造成意料之外的后果呢?如果您不知道如何發(fā)展您的DevOps團隊或認為DevOps轉型舉步維艱,不妨看看戴爾科技集團是怎么做的。
戴爾科技集團相信:DevOps不是簡單地將職責劃分為職能團隊,而是統(tǒng)籌全局,重點關注整個生命周期,通過制定周密的戰(zhàn)略計劃來實現(xiàn)DevOps的轉型與發(fā)展。
我們的DevOps團隊致力于創(chuàng)建開發(fā)人員所需的所有自動化服務,并取得了突破性的成果:現(xiàn)在,我們可以讓開發(fā)人員在5到30分鐘內構建他們需要的東西,整體開發(fā)人員生產力提高35%以上。
戴爾科技集團的戰(zhàn)略基于三大戰(zhàn)略計劃:API標準化、自動化生態(tài)系統(tǒng)集成、現(xiàn)實世界的經驗主導。
API標準化
自動化從標準化的API開始。我們以API為先的方式開發(fā)代碼,進一步提升開發(fā)效率,開發(fā)人員可以通過我們的API市場分享API,供IT和其他內部業(yè)務單位和部門使用,包括外部企業(yè)、客戶和合作伙伴。
戴爾支持兩種類型的API標準:用于產品的產品API以及社區(qū)支持的開放API。產品API是一組標準化的RESTful API,由我們的專家定義,以允許與戴爾產品進行基于軟件的通信。開放行業(yè)API則由鼓勵協(xié)作并允許快速開發(fā)的標準化機構定義。
當然,這也使得我們的諸多產品能夠支持各種API,例如Dell PoweFlex提供的基于標準的開放式API和自定義Ansible Modules,以簡化與第三方或自定義工作流的集成。
最新基于PowerEdge15G服務器的PowerFlex節(jié)點采用英特爾至強®Platinum®處理器,更高的CPU、更多的內存,帶來極高的性能。
PowerFlex API作為PowerFlex Manager以及PowerFlex Gateway軟件包的一部分安裝,隨著新功能和PowerFlex軟件進行升級和更改,十分適用于希望自動化PowerFlex部署、配置和管理任務的客戶。
自動化生態(tài)系統(tǒng)集成
自動化不是萬能的,但沒有自動化是萬萬不能的。戴爾通過使用我們的標準API與常見的自動化框架的集成來實現(xiàn)自動化生態(tài)系統(tǒng)集成。
我們的數(shù)字化團隊也在自行開發(fā)先進的自動化工具,以在標準CSI驅動程序支持的基本功能之外添加關鍵的企業(yè)功能。從開發(fā)人員編寫測試用例到測試代碼,所有的步驟都依靠自動化,有效解決了開發(fā)人員過去操作繁瑣,浪費時間的問題。
現(xiàn)實世界的經驗主導
在戴爾科技集團,我們已擁有多年的DevOps轉型經驗。在整個轉型過程中,戴爾數(shù)字部門不斷提供有關DevOps各個方面的培訓,了解他們的特定用例和技術堆棧。迄今為止,戴爾數(shù)字部門已成功培訓了超過5000名開發(fā)人員、產品經理和工程負責人。
現(xiàn)在,我們正積極的參與IT社區(qū),例如云原生計算基金會、Linux 基金會、桌面管理工作組、開放計算項目等等,畢竟沒有什么東西能夠比實踐得來的經驗更寶貴,站在巨人的肩膀上往往能夠看的更遠。
END
如果您想了解更多有關戴爾科技的產品和解決方案信息,請掃描以下二維碼咨詢戴爾官方客服。