【前言】

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í)興起?

[[132398]]

五六年前PaaS的概念才剛剛興起，當(dāng)時(shí)有很多人(包括我自己)都認(rèn)為運(yùn)維這個(gè)職業(yè)將會(huì)因此走向衰亡。因?yàn)槟憧梢园堰\(yùn)維的工作交給PaaS平臺(tái)，然后去專注于自己所擅長(zhǎng)的事情，所以應(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ī)模的增長(zhǎng)，企業(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)維”的工具。

#p#

讓我們不要再忘了運(yùn)維

[[132399]]

然而，我感覺我們?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)于這些，我們非常歡迎得到您的一些想法和反饋。

原文鏈接：http://dockerone.com/article/322