被迫妥協(xié)：共同研發(fā)的 RunC 意味著什么？
Docker 一開始就一家獨(dú)大，并且并不是一種開放的態(tài)姿態(tài)在做，所以很早之前 Google 就投資了 CoreOS 來做競(jìng)爭(zhēng)的容器——Rocket.那時(shí)是三家鼎立：Docker/Rocket/Warden，為了避免慘烈的競(jìng)爭(zhēng)，大家終于統(tǒng)一意見，決定成立 OCI 做統(tǒng)一的容器運(yùn)行時(shí)——RunC，OCI 成立后加入了大約50家廠商。出于對(duì) Docker 封閉化商業(yè)式發(fā)展的擔(dān)心，OCI 商討出這種方案：以 RunC 為核心重新構(gòu)建生態(tài)圈，并且通過插件來弱化容器在 CaaS 生態(tài)圈的重要性。
OCI 負(fù)責(zé)的 RunC 是非常小的運(yùn)行核，其目的在于提供一個(gè)干凈簡(jiǎn)單的運(yùn)行環(huán)境，他就是負(fù)責(zé)隔離 CPU、內(nèi)存、網(wǎng)絡(luò)等形成一個(gè)運(yùn)行環(huán)境，可以看作一個(gè)小的操作系統(tǒng)：現(xiàn)在 OCI 只負(fù)責(zé)這些，尚未擴(kuò)大到更大的范圍，其實(shí)這樣是小而美的，這樣的是業(yè)界所最需要的。
當(dāng)然， RunC 的生態(tài)發(fā)展就會(huì)局限在企業(yè)級(jí)別應(yīng)用中，并因此具有不同的發(fā)展目標(biāo)：RunC 不是要提供多少種工具，而是要非常穩(wěn)定。 接下來需要做的是可能是添加完善一些功能，比如將 Docker 鏡像導(dǎo)進(jìn)來，與各種插件更好地結(jié)合（動(dòng)態(tài)化即插即用），熱啟動(dòng)和遷移。這些功能是企業(yè)需要的，但是對(duì)開發(fā)者沒什么作用。以熱遷移為例，從一臺(tái)虛擬機(jī)遷移到另外一臺(tái)虛擬機(jī)，但是開發(fā)者可能本來就一臺(tái)機(jī)器并沒有這個(gè)需要。
因?yàn)?RunC 是 Docker 的一個(gè)子集，所以單純從代碼量上來講，RunC 只占 Docker 的百分之幾。相比而言，Docker 有豐富工具，更貼近于開發(fā)者。這也是為什么很多個(gè)人開發(fā)者并不知道 RunC，因?yàn)镽unC的使用者都是 Mesos、K8S 和 Cloud Foundry 這類 CaaS 廠商。
在 RunC 早期，Docker 是主要貢獻(xiàn)者（在我看來，如果 Docker 不參與 RunC 的發(fā)展就意味著和容器生態(tài)圈決裂）；后來隨著各大廠商對(duì) RunC 大幅貢獻(xiàn)代碼，RunC 的代碼貢獻(xiàn)者越來越多樣化，Docker 所占比例在持續(xù)下降。通過不斷迭代，RunC 一定會(huì)越來越成熟，它已經(jīng)在生產(chǎn)環(huán)境中開始積累技術(shù)了，Cloud Foundry 已經(jīng)有不少全球重量級(jí)客戶在用內(nèi)置 RunC 容器，經(jīng)歷的很多坑的 bug 修補(bǔ)已經(jīng)回饋到 RunC 源碼中去了。
Docker 的運(yùn)行內(nèi)核雖然是從 1.11 支持 RunC 的，但是 Docker 的心態(tài)是很復(fù)雜的：一方面作為 OCI 成員必須支持 RunC，但是另一方面他會(huì)擔(dān)心 RunC 對(duì) Docker 的替代的威脅。
危機(jī)解讀： 適合Docker公司的路在何方？
坦率而言，我認(rèn)為 Docker 進(jìn)軍編排界并沒有優(yōu)勢(shì)，因?yàn)樗狈ζ髽I(yè)級(jí)基因。
Docker 更適合在容器本身的技術(shù)，今年 Docker 力推 Swarm，把資源花在了集群管理上，這其實(shí)并不是 Docker 技術(shù)的初心。當(dāng)時(shí) Docker 迅速流行是因?yàn)楹?jiǎn)單易用，而后來走卻想把太多東西塞到 Docker 中。
在從目前適用場(chǎng)景選擇來看，一般而言，使用 Docker Swarm 的都是小企業(yè)的小規(guī)模應(yīng)用，而大企業(yè)采用的都是 Mesos、K8S 或 Cloud Foundry.（當(dāng)然有極少的案例采用了 Docker 的 Swarm，但是從比例而言這并不具普遍性）。因?yàn)樽畛醯脑O(shè)計(jì)來源就不一樣，前者是從開發(fā)者角度設(shè)計(jì)，而 Mesos、K8S 和 Cloud Foundry 是從企業(yè)中來，有很多企業(yè)運(yùn)維的實(shí)戰(zhàn)積累。
Docker 也就是小幾百人的公司，并不算巨頭公司，做企業(yè)級(jí)市場(chǎng)比較吃力，而做中小企業(yè)或是個(gè)人用戶市場(chǎng)這種思路更適合 Docker 的盈利模式。在我看來，不論國(guó)內(nèi)國(guó)外，做企業(yè)級(jí)市場(chǎng)一定需要很多銷售去和企業(yè)用戶打交道聊需求，項(xiàng)目實(shí)施的時(shí)候往往要根據(jù)客戶的需求做定制，要知道每個(gè)企業(yè)用戶的需求是不一樣的，沒有辦法進(jìn)行完全統(tǒng)一的標(biāo)準(zhǔn)化，那定制化的需求就需要一定規(guī)模的人力投入，每個(gè)項(xiàng)目都需要一定的人員資源投入，小公司很難做這種投入。在我看來，小作坊做企業(yè)用戶還是面臨很大的挑戰(zhàn)。
從企業(yè)級(jí)需求來看，比如企業(yè)一個(gè)考慮就是，一定要前后版本兼容，否則就無法升級(jí)。而這恰恰是 Docker 不 care，比如個(gè)人用戶可以隨時(shí)重啟機(jī)器，開發(fā)者在遇到問題可以重啟，在企業(yè)級(jí)的思路不是這樣的。Docker 的思路并不是做企業(yè)級(jí) IT 應(yīng)用系統(tǒng)的思路，所以如果應(yīng)用到企業(yè)級(jí)應(yīng)用中一定會(huì)遇到問題。至于很多互聯(lián)網(wǎng)公司在應(yīng)用 Docker，很多互聯(lián)網(wǎng)公司也是在摸索，包括自己做 Docker 集群管理的不少，但自己做 Docker 集群管理的基本都開始開始轉(zhuǎn)向 K8s、Cloud Foundry、Mesos 這些專業(yè)的容器集群管理軟件了，這是很明顯的趨勢(shì)，那么這些互聯(lián)網(wǎng)企業(yè)當(dāng)初花資源做的集群管理基本就是被廢棄，即使現(xiàn)在沒轉(zhuǎn)的遲早要轉(zhuǎn)型到 CF（Cloud Foundry） / K8s / Mesos.對(duì)于企業(yè)客戶來說，這種試錯(cuò)是得不償失的，因?yàn)槠髽I(yè)客戶沒有這么多人去研究開發(fā)容器集群管理軟件。但對(duì)互聯(lián)網(wǎng)公司來說，這個(gè)試錯(cuò)是可以接受的，畢竟養(yǎng)這么多工程師其中有一部分就是通過不斷的、或大或小的試錯(cuò)而優(yōu)化技術(shù)的。