解讀技術雷達中的 DevOps 發(fā)展趨勢

今年4月份丧靡,我第一次以主編的身份參加技術雷達的翻譯工作。有幸第一時間參加到技術雷達的翻譯過程中。通過我在翻譯其間對條目的了解和觀察,我寫下了《DevOps發(fā)展的九個趨勢

今年11月份涩僻,我再一次以執(zhí)行主編的身份參加第17期技術雷達的翻譯工作。17 期技術雷達中兩大主題:Kubernetes 和 Cloud as the New Normal 都是 DevOps 相關的变泄。而且本期技術雷達涌現了眾多 DevOps 相關的新條目令哟。一方面說明了 DevOps 在 IT 業(yè)的重要性日漸增加恼琼,一方面也支撐起了 DevOps 社區(qū)在工具和實踐上的創(chuàng)新妨蛹。雖然每個人對 DevOps 的理解不盡相同,但能持續(xù)的著眼在具體的問題并提供實際的解決方案則是值得稱道的晴竞。

這些新的變化對我上一期的 DevOps 技術趨勢判斷和發(fā)展有了新的思考和認識蛙卤,借由此文分享給大家。

回顧2017年 DevOps 發(fā)展

在今年 4月第16期技術雷達發(fā)布后噩死,我分析了 DevOps 發(fā)展的九個趨勢颤难。我認為這九個趨勢代表了2017年 DevOps 技術的發(fā)展方向。讓我們來結合最新的技術雷達回顧一下2017年這些趨勢的發(fā)展已维。

趨勢1:微服務目前仍然是DevOps技術應用和發(fā)展的主要領域

現狀:微服務的相關技術仍然不斷涌現行嗤。但人們似乎過于樂觀的估計了微服務的投資回報速度。架構演進是一個長期的過程垛耳,而實踐中的陷阱和問題越來越多栅屏。不斷涌現的諸多工具和解決方案說明了微服務的反思已經開始飘千。讓我們期待更多微服務的案例出現。

趨勢2:以Docker為核心的數據中心方案逐漸走向成熟

現狀:Kubernetes 生態(tài)圈在 Docker 編排工具的爭霸大戰(zhàn)中笑道了最后栈雳,本期技術雷達把 Kubernetes 移動到了“采用”中护奈,證明 Kubernetes 是經得住時間考驗的工具。隨著越來越多的廠商和社區(qū)開始圍繞 Kubernetes 構建自己的產品哥纫,我相信基于 Kubernetes 的產品和工具會越來越多霉旗。

趨勢3:不完整的DevOps實踐阻礙著DevOps的發(fā)展

現狀:雖然 DevOps 社區(qū)的活躍程度催生了一大批的工具和平臺,但卻在推廣實踐上發(fā)力不足蛀骇。接受了局部技術改進后的 DevOps 演進似乎立刻停止厌秒,使得 DevOps 難以發(fā)揮出更大的價值。隨著時間的發(fā)展松靡,這種局面會愈來愈常見简僧。如 方法論的推廣落后于工具的發(fā)展,那么 DevOps 運動的壽終正寢也將為期不遠雕欺。

趨勢4:領域特定的DevOps實踐開始出現

現狀:雖然并沒有十分特別的領域特定的 DevOps 技術出現岛马。但受到 DevOps 啟發(fā)的 DesignOps 和 DevSecOps 也分別有了自己的社區(qū)群體。期待它們在未來有進一步的表現屠列。

趨勢5:采用DevOps進行技術債務重組和技術資產管理

結果:我寫下這個趨勢的第二周就進入了這樣一個技術資產管理項目并工作到現在啦逆。在這 6 個月中我和同事們采用了 DevOps 理念和技術進行技術資產重組和互聯網企業(yè) IT 資產并購,并體會到了其中的諸多益處笛洛,大大節(jié)約了產品上線時間和上線風險夏志,而且產品的開支的隨著時間以更快的速度遞減。隨著 CloudNative 的技術和概念的成熟苛让,相信這類的項目和案例會越來越豐富沟蔑。

趨勢6:安全成為推動DevOps全面發(fā)展的重要力量

結果:OWASP Top10 和 OWASP Top10 Mobile 的姍姍來遲雖然并未進入本期技術雷達。但并不表明技術雷達對安全有所松懈狱杰,這反而是一種更加負責的態(tài)度瘦材。而安全相關的實踐已從使用工?具進入安全場景的設計。例如最新期的 3Rs 安全 和 上一期就提到的 KeyCloak仿畸,以及本期提到的用于安全的 Sidecar 模式赦拘。

趨勢7:Windows Server和.NET平臺下的DevOps技術潛力巨大

現狀:隨著 Azrue 的成熟 和 Windows Conatiners 的推出亭敢,Windows 領域的 DevOps 關鍵工具鏈即將打通。但是 MS-DevOps 的“最后一公里”顯得比較艱難。MS-DevOps 的社區(qū)的發(fā)展并不活躍民效,使得 Windows Server 的相關實踐略顯不足惹悄,這進一步限制了 DevOps 相關技術在 Windows 平臺上的作為鸯旁。

趨勢8:非功能性自動化測試工具的逐漸完備

現狀:更多的工具開始圍繞“自動化測試”展開赠堵,關于自動化測試為開發(fā)帶來的諸多益處以無需多言。在本期技術雷達里我們看到了更多這樣的技術出現放可,例如:TDD in Containers谒臼,Flood.io 用于負載測試唱逢,Heptio Sonobuoy 用于合規(guī)測試。而一個成熟穩(wěn)健的架構屋休,必須要經得起來自各方面的測試坞古。

趨勢9:Python成為DevOps工作中所不可或缺的語言

現狀:Python 仍然重要,但 Go 語言在 Ops 相關工具中的地位也在逐步提升劫樟。

2018 年的 DevOps 技術的發(fā)展趨勢

雖然條目眾多痪枫,但我們可以從技術雷達中整理出 4 個 DevOps 發(fā)展脈絡:

趨勢1:微服務的實踐進入深水區(qū)

微服務在部分企業(yè)的成功給所有的企業(yè)描述了一個美好的愿景,但通往這條美好之路的路程則并不那么一帆風順叠艳。

微服務是成功的結果奶陈,而非成功的原因,我把成功的架構轉型經驗的結果架構稱之為微服務架構附较。但這并不是微服務成功的動因吃粒,畢竟這些最初成功應用微服務企業(yè)最開始的時候并沒有“微服務”的概念。而能夠讓微服務成功一定是在特定場景下遵守了某些重要的原則拒课。而這些特定的場景和原則似乎被人忽視徐勃,而只能從表象上描述這一成功的結果。

隨著微服務在各種場景下的應用早像,針對不同行業(yè)僻肖,不同組織,不同技術上下文的實踐被慢慢總結出來卢鹦。有些是成功經驗臀脏,有些則是反思。例如: Service Mesh (服務嚙合)和 Overambitious API gateways(過度龐大的API網關產品)就是相互關聯的技術冀自。而 KONG API Gateway 就是一個十分不錯的 API 網關工具揉稚,但結合了不同的上下文,可以得到不同的結果熬粗。

成功微服務實踐者一直在強調康威定理的重要性搀玖,而現實中的企業(yè)往往忽視條經驗。同樣的技術和工具荐糜,在不同的業(yè)務上下文和組織結構里巷怜,就會得出不同的結果葛超。Kafka 的使用并不能表示你正在往正確的路上走暴氏,僅僅替換了工具而非思維和架構模式會將你帶入 Recreating ESB antipatterns with Kafka(用 Kafka 重建 ESB 反模式)。所以绣张,采用某些技術或工具一定要識別對正確的場景答渔。

?另一方面,成功的經驗和重復被證明成功的微服務實踐則作為框架被流傳了下來侥涵。Spring Cloud 作為 微服務解決方案的杰出代表繼續(xù)在技術雷達中擁有自己的一席之地沼撕,以至于現在任何一本關于微服務的書都是以 Spring Cloud 展開的宋雏。此外,技術雷達里有增添了 Spring Cloud 的新成員:Spring Cloud Contract 是和 Spring 框架結合緊密的消費者驅動契約測試的工具务豺。這說明消費者驅動的契約測試被證明是有效的微服務測試方法磨总。盡管技術雷達第一次提出消費者驅動的契約測試已經過去了3年。

當微服務的架構轉型到了深水區(qū)笼沥,微服務的標準實踐架構即將出現蚪燕,一掃微服務生態(tài)圈的混亂情況。就如曾經發(fā)生在 Docker 社區(qū)中的一樣奔浅。

趨勢2:如果你正在使用 Docker馆纳,請向 Kubernetes 遷移

技術雷達一直保持著對 Docker 社區(qū)的關注度,因為這是我們普遍采用的技術汹桦。但在大規(guī)模的使用上面鲁驶,技術雷達則相對保守,盡管技術雷達從 2015 年就開始關注 Kubernetes 舞骆,但直到這次才放到“采用”區(qū)域里钥弯,證明了 Kubernetes 已經非常成熟。圍繞著 Kubernetes 生態(tài)工具鏈也逐漸完善督禽,無論是廠商(Google 的 GKE 解決方案寿羞,還是 AWS 的 EKS)提供的完整平臺。還是社區(qū)的 Kops 和 Sonobuoy 這樣的赂蠢,都不斷在增強 Kubernetes 在生產環(huán)境的實際應用能力绪穆。

如果你之前也在觀望容器大戰(zhàn),現在可以果斷進入 Kubernetes 了虱岂,如果你準備在生產環(huán)境使用 Docker玖院,請優(yōu)先考慮 Kubernetes。如果你已經用了 Kubernetes第岖,那么恭喜你难菌!希望你能將你的杰出實踐經驗分享給大家。

趨勢3:Cloud Native DevOps

云計算技術不光極大降低了 IT 運營成本蔑滓,更改變了開發(fā)和運維的工作方式郊酒。DevOps 在企業(yè)級的應用遇到的更多阻力在云端,無論是應用架構還是工作方式键袱。

很多企業(yè)仍然僅僅把云平臺當做一個 “遠程托管機房”燎窘,并沒有發(fā)揮出云平臺組件和 SDK 帶來的組合性優(yōu)勢。

CloudNative 最大的思維轉變當屬 Stateless Infrastructure(無狀態(tài)基礎設施)蹄咖。這樣可以大幅度保障應用的可用性和水平擴展能力褐健,當傳統(tǒng)的計算資源和存儲資源已經通過云計算技術達到了海量。應用的瓶頸就來自于應用架構和基礎設施結構澜汤。如果還在思考基礎設施的狀態(tài)如何監(jiān)控和保存蚜迅,就又進入了老的思維模式舵匾,只不過換了新的工具而已。

Serverless Framework 和 Apex 框架就是采用 CloudNative 思維的代表谁不,在實際的應用中它顛覆了我們對軟件開發(fā)和運維的很多認識坐梯。把基礎設施當做一個資源相對無限的狀態(tài)機,你的應用就是這個狀態(tài)機的狀態(tài)配置刹帕,并通過版本化的手段在線保存狀態(tài)烛缔。把對基礎設施和設備的依賴降低到最小:只需要一個代碼庫轩拨。

而在這樣的情形下践瓷,我們不需要構建一套開發(fā)環(huán)境和測試環(huán)境(你并不想只十幾行代碼就需要搭建一套虛擬的云計算環(huán)境)。而全部都在生產環(huán)境上工作亡蓉,只不過生產環(huán)境有高級別的隔離晕翠,且各部分狀態(tài)不同,有的是在生產狀態(tài)砍濒,有的是在開發(fā)測試狀態(tài)淋肾。

此外,更多的開發(fā)基礎設施和測試工具以平臺的形式也相繼推出爸邢,它們不光提升了安全性和穩(wěn)定性樊卓,更降低了企業(yè) IT 資產總和管理成本。例如:CircleCI 和 BuildKite 就是持續(xù)集成服務器的平臺化實現杠河,只需要在代碼里有很少的配置就可以解決搭建整套持續(xù)交付流水線的各種繁瑣步驟和功能碌尔。Flood.io 則是通過在云端模擬大量的用戶訪問請求進行負載測試,這不光有助于你發(fā)現自己的基礎設施和應用的瓶頸券敌,更能幫你預演在高流量的狀況下整個團隊的響應能力唾戚。

由于眾所周知的原因,我們無法訪問本期技術雷達提到的 GCP(Google Cloud Platform)待诅,有限的使用 AWS 和 Azure叹坦,但仍然無法阻擋云計算的發(fā)展迅猛之勢。

當云計算平臺提供了一系列廉價而又靈活的基礎設施之后卑雁。實踐 DevOps 的你需要思考如何把傳統(tǒng)的實踐推向極致募书。

趨勢4:自動化,更多的自動化测蹲!

自動化永遠是 DevOps 的核心主題之一莹捡,各種自動化測試工具和平臺的興起似乎在說明我們以往的自動化測試是不夠的。新的自動化測試工具和方法正在越來越多弛房。本期我們看到了關于 TDD in Containers 和 Sonobuoy道盏,分別是而柑,由于新版本 Chrome 的 Headless 模式的發(fā)布文捶,未來的自動化測試則會越來越多荷逞,越來越完整。

我們可以把基礎設施想象成一個軟件產品粹排,通過基礎設施流水線構建這樣的產品种远。我們甚至可以使用 基礎設施流水線把生產環(huán)境的更新做到極致:每天進行生產環(huán)境的從頭構建,自動化配置網絡以及基礎設施顽耳,自動化還原數據庫備份坠敷,每天產生一個可用的架構。這樣的生產環(huán)境上就會有兩個架構:一個生產中射富,一個待生產膝迎。你不在需要開發(fā)環(huán)境和測試環(huán)境,每天的工作都保存在待生產的架構上胰耗。由于第二天就要發(fā)布限次,因此今天會把所有的工作控制在明天發(fā)布之前完畢,而且要符合生產要求柴灯。這樣就可以迫使團隊把自己的工作自動化并且提升交付質量卖漫。也避免在自己的電腦上或者某個代碼分支上存儲很久。

數據中心的災后重建就是極為痛苦的事情赠群,因此需要做災備預演羊始。而現有的階段性災難預演已經無法滿足要求。所以對于云端的基礎設施來說查描,有災難要預演突委,沒有災難要制造災難預演。這樣可以使你基礎設施和應用架構達到極端的可用性和可恢復性冬三,同時實現了 3Rs? 安全鸯两。就像《持續(xù)交付》一書中所說的:經常做那些讓你感到痛苦的事情。由于 AWS 提供了 VPC 級別的隔離长豁,我已經可以通過 CloudFormation + Ansible 做到這一點钧唐,未來會把相關經驗分享給大家。

另一方面匠襟,我們看到了 基于算法的IT運維(Algorithmic IT Operations)钝侠,甚至提出了 AIOps 的概念。但基于算法的運維仍處在初步階段酸舍。雖然我很樂于看見新的技術發(fā)展趨勢帅韧,但每個領域的 AI 熱潮是掩蓋了真正的問題,還是讓我們更快的找到了問題的正確答案啃勉?還有待觀察忽舟。

最后

17 期的技術雷達的關注重點在 DevOps 上。一方面說明企業(yè)級應用正在全面的向云遷移,另一方面也說明云平臺上的技術發(fā)展也在同樣進步叮阅。在這個過程中我們遇到了新的問題刁品,同時也遇到了新的機遇。當前這一系列的 DevOps 技術的浪潮會帶來什么樣的發(fā)展浩姥,明年的技術雷達將會揭曉挑随。

?著作權歸作者所有,轉載或內容合作請聯系作者
禁止轉載,如需轉載請通過簡信或評論聯系作者勒叠。
  • 序言:七十年代末兜挨,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子眯分,更是在濱河造成了極大的恐慌拌汇,老刑警劉巖,帶你破解...
    沈念sama閱讀 222,104評論 6 515
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件弊决,死亡現場離奇詭異担猛,居然都是意外死亡,警方通過查閱死者的電腦和手機丢氢,發(fā)現死者居然都...
    沈念sama閱讀 94,816評論 3 399
  • 文/潘曉璐 我一進店門傅联,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人疚察,你說我怎么就攤上這事蒸走。” “怎么了貌嫡?”我有些...
    開封第一講書人閱讀 168,697評論 0 360
  • 文/不壞的土叔 我叫張陵比驻,是天一觀的道長。 經常有香客問我岛抄,道長别惦,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 59,836評論 1 298
  • 正文 為了忘掉前任夫椭,我火速辦了婚禮掸掸,結果婚禮上,老公的妹妹穿的比我還像新娘蹭秋。我一直安慰自己扰付,他們只是感情好,可當我...
    茶點故事閱讀 68,851評論 6 397
  • 文/花漫 我一把揭開白布仁讨。 她就那樣靜靜地躺著羽莺,像睡著了一般。 火紅的嫁衣襯著肌膚如雪洞豁。 梳的紋絲不亂的頭發(fā)上盐固,一...
    開封第一講書人閱讀 52,441評論 1 310
  • 那天荒给,我揣著相機與錄音,去河邊找鬼刁卜。 笑死志电,一個胖子當著我的面吹牛,可吹牛的內容都是我干的长酗。 我是一名探鬼主播溪北,決...
    沈念sama閱讀 40,992評論 3 421
  • 文/蒼蘭香墨 我猛地睜開眼桐绒,長吁一口氣:“原來是場噩夢啊……” “哼夺脾!你這毒婦竟也來了?” 一聲冷哼從身側響起茉继,我...
    開封第一講書人閱讀 39,899評論 0 276
  • 序言:老撾萬榮一對情侶失蹤咧叭,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后烁竭,有當地人在樹林里發(fā)現了一具尸體菲茬,經...
    沈念sama閱讀 46,457評論 1 318
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 38,529評論 3 341
  • 正文 我和宋清朗相戀三年派撕,在試婚紗的時候發(fā)現自己被綠了婉弹。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,664評論 1 352
  • 序言:一個原本活蹦亂跳的男人離奇死亡终吼,死狀恐怖镀赌,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情际跪,我是刑警寧澤商佛,帶...
    沈念sama閱讀 36,346評論 5 350
  • 正文 年R本政府宣布,位于F島的核電站姆打,受9級特大地震影響良姆,放射性物質發(fā)生泄漏。R本人自食惡果不足惜幔戏,卻給世界環(huán)境...
    茶點故事閱讀 42,025評論 3 334
  • 文/蒙蒙 一玛追、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧闲延,春花似錦豹缀、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,511評論 0 24
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至侍匙,卻和暖如春氮惯,著一層夾襖步出監(jiān)牢的瞬間叮雳,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,611評論 1 272
  • 我被黑心中介騙來泰國打工妇汗, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留帘不,地道東北人。 一個月前我還...
    沈念sama閱讀 49,081評論 3 377
  • 正文 我出身青樓杨箭,卻偏偏與公主長得像寞焙,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子互婿,可洞房花燭夜當晚...
    茶點故事閱讀 45,675評論 2 359

推薦閱讀更多精彩內容