【前言】
PaaS并不是一個(gè)陌生的話題,在新興的容器世界里,我們?nèi)绾慰创\(yùn)維和PaaS的關(guān)系呢? 又如何重新思考Dev與Ops的定位呢? 本文作者就此分享了自己的一些獨(dú)特見解。比如作者說:Docker 最棒的一點(diǎn)在于它為開發(fā)和運(yùn)維劃分了一個(gè)清晰的界線:任何在容器內(nèi)部的都是開發(fā)所關(guān)注的,而外部則是運(yùn)維的天下。
是否還記得PaaS何時(shí)興起?
五六年前PaaS的概念才剛剛興起,當(dāng)時(shí)有很多人(包括我自己)都認(rèn)為運(yùn)維這個(gè)職業(yè)將會(huì)因此走向衰亡。因?yàn)槟憧梢园堰\(yùn)維的工作交給PaaS平臺(tái),然后去專注于自己所擅長的事情,所以應(yīng)該不會(huì)再有人愿意去干那些和機(jī)器打交道的基礎(chǔ)服務(wù)方面的雜活吧?
現(xiàn)在,六年過去了,我們最終看到的是PaaS大量失敗的案例,我開始意識(shí)到我錯(cuò)了,PaaS 并不是我想要的未來,它并不能夠完全解決基礎(chǔ)服務(wù)方面的一些難題,而僅僅只是讓這些問題稍有緩和罷了。
在一開始,PaaS服務(wù)提供商每個(gè)月投入數(shù)百到數(shù)千美金的經(jīng)費(fèi)和資源培養(yǎng)客戶,而最后只能眼睜睜看著他們離開,然后投入到云服務(wù)提供商的懷抱。
眼下的現(xiàn)實(shí)情況是公共的PaaS服務(wù)已經(jīng)淪為一些菜鳥入門學(xué)習(xí)的平臺(tái),而那些游戲的勝利者們已經(jīng)拋棄了PaaS,而選擇在眾多的云服務(wù)平臺(tái)上搭建自己的服務(wù)器來承載他們的服務(wù)。
我之前曾經(jīng)寫過一篇文章,講述了我為什么認(rèn)為如此創(chuàng)新和流行的公共PaaS服務(wù)不能完全征服世界的一些見解,所以在這邊便不再贅述。但是這里有一個(gè)論點(diǎn)我想再深入強(qiáng)調(diào)一下,就是我個(gè)人認(rèn)為我們也許又犯了一個(gè)同樣的錯(cuò)誤,那就是“運(yùn)維這個(gè)職業(yè)即將消亡”的這個(gè)預(yù)測(cè)。
相信從公共PaaS服務(wù)到開發(fā)者們所做的每件需要運(yùn)維(我能稱之為DevOps嗎?)參與的事情里我們看到的和解讀到的,你可以感覺到“運(yùn)維”其實(shí)離我們并不是很遙遠(yuǎn),然而它始終處在一個(gè)即將消亡的風(fēng)口浪尖。我想這種“運(yùn)維即將消亡”的思想多數(shù)來自于我們之中那些幸運(yùn)的沒有去到一個(gè)大型或者老牌企業(yè)工作過的朋友,或者是單純以技術(shù)角度去看待這個(gè)問題而非企業(yè)的角度的朋友。
任何企業(yè)都依然需要運(yùn)維的工作。如果他們并非如此的話,那么他們一定是把這些事情重新定義了一下(就比如開發(fā)穿上了運(yùn)維的帽子,然后干起了搬機(jī)器的活)或者是臨時(shí)的把這些事情外包給了一些公共PaaS服務(wù)提供商,就像現(xiàn)在很多企業(yè)實(shí)際所做的那樣。
這并不是簡(jiǎn)單的技術(shù)架構(gòu)問題,也和業(yè)務(wù)結(jié)構(gòu)有一定關(guān)系。在業(yè)務(wù)邏輯里,對(duì)于創(chuàng)新(Dev)和保持穩(wěn)定收益(Ops)有各自不同的生命周期,而我們有充分的理由告訴那些想用所研發(fā)的技術(shù)在大的方向上使得企業(yè)騰飛的開發(fā)者們大可不必承擔(dān)所有的事情,而他們也必須認(rèn)識(shí)到這一點(diǎn)。
在這里,就我個(gè)人來說,我覺得公共PaaS沒能真正興盛的最大原因在于:隨著業(yè)務(wù)規(guī)模的增長,企業(yè)們需要規(guī)范和簡(jiǎn)化他們的運(yùn)維,而這就造成了運(yùn)維人員重新從外部PaaS服務(wù)提供商接管過來本就屬于運(yùn)維的工作(或者,更恰當(dāng)?shù)恼f,是這些企業(yè)會(huì)將開發(fā)者們安排到不同的業(yè)務(wù)周期)。反之,這也就是為什么像Cloudfoundry這樣的私有PaaS服務(wù)比他們的公共服務(wù)兄弟做的更出彩的原因之所在:他們是運(yùn)維人員的工具,也同樣迎合開發(fā)人員的需求。他們之所以如此成功是因?yàn)樗麄冋J(rèn)識(shí)到了運(yùn)維真正的存在價(jià)值:他們充當(dāng)?shù)氖且粋€(gè)為運(yùn)維人員提供服務(wù)的資源管理工具集而不是一個(gè)發(fā)明出來用以替代“運(yùn)維”的工具。
讓我們不要再忘了運(yùn)維
然而,我感覺我們?cè)谶@個(gè)新興的容器世界也許又會(huì)再次犯下我們之前在公共PaaS所犯過的同樣的錯(cuò)誤。大多數(shù)用于在生產(chǎn)環(huán)境運(yùn)行和管理容器的解決方案顯得過于以開發(fā)為中心了。他們并沒有一個(gè)清晰的界限指明應(yīng)用應(yīng)該如何規(guī)范的停止服務(wù),基礎(chǔ)服務(wù)的一些需求應(yīng)該怎樣去實(shí)現(xiàn)。
類似Docker Swarm這樣的工具是在概念的層次上指明開發(fā)和運(yùn)維如何在最初從各自的角度去使用這些工具集的很好的例子,然而在應(yīng)用規(guī)范方面我們?nèi)匀挥写罅康墓ぷ餍枰プ觯涸鯓尤ザx服務(wù)的概念,他們?nèi)绾稳ジ渌膶?shí)體交互,在與其它實(shí)體交互時(shí)他們應(yīng)該使用什么樣的協(xié)議,等等。這些都是應(yīng)用層面規(guī)范的問題。
接下來我們需要面對(duì)的是一系列的運(yùn)維方面的問題:怎樣把資源裝載到我們的基礎(chǔ)架構(gòu),如何構(gòu)建我們所需要的實(shí)體,如何約束每個(gè)服務(wù)的服務(wù)范疇以及他們?nèi)绾味ㄎ黄渌从郴A(chǔ)服務(wù)配置的實(shí)體(譯者注:比如說定位到同一個(gè)IDC或網(wǎng)絡(luò)通信質(zhì)量高的服務(wù)實(shí)體,而不是隨機(jī)選擇),等等。
當(dāng)我關(guān)注到類似Swarm和Compose這樣從不同的功能清晰劃分的工具集時(shí)內(nèi)心備受鼓舞。然而它們并沒有在API中對(duì)開發(fā)和運(yùn)維做很大的區(qū)分。舉個(gè)例子,Compose(持續(xù)工作中的)傾向于支持所有的Docker CLI命令行選項(xiàng)參數(shù),而大部分(也許不是全部)的Docker CLI 命令行參數(shù)是純粹的以開發(fā)為中心設(shè)計(jì)的。
Docker 最棒的一點(diǎn)在于它為開發(fā)和運(yùn)維劃分了一個(gè)清晰的界線:任何在容器內(nèi)部的都是開發(fā)所關(guān)注的,而外部則是運(yùn)維的天下。當(dāng)前版本的Compose API以及開發(fā)的 Swarm 在某種程度上來說反而是模糊了這個(gè)劃分的邊界。
我們正在努力試圖讓這個(gè)劃分變得更清晰并且體現(xiàn)到實(shí)際的企業(yè)生產(chǎn)業(yè)務(wù)中。manifest.yml和services.yml的劃分或是我們UI的構(gòu)建方式都是一些我們?cè)噲D推動(dòng)這一愿景的最初的嘗試。關(guān)于這些,我們非常歡迎得到您的一些想法和反饋。