作者 | 馬超
出品 | CSDN(ID:CSDNnews)
開源真是火了,近些年成功的IT專案像TensorFlow、RocketMQ、TDEngine都是開源專案,而且這種火爆還出了圈,連帶著RISC-V這種準開源的晶片也成為了各方爭搶的香餑餑。但是如果仔細觀察這一片開源火爆的背後其實也有不少隱憂,由於開源只是一種鬆散、開放的合作方式,這種合作方式往往能夠帶來人們意想不到的高價值產出,但由於目前主流的開源協議往往沒有對於後續價值分配做出嚴格約定,這也就造成了諸如“某大廠上開源恥辱牆”、“開發者上門要索要程式碼”的鬧劇頻頻出現,但這些小紛爭和開源巨大的利益蛋糕比起來都是小場面,目前開源界的三大戰役主要是Dockers vs k8s、紅帽Linux vs Cent OS以及亞馬遜 vs Elastic,而這其中Docker的發展軌跡最為典型,也最值得我們思考。
Dockers Desktop收費如飲鴆止渴,加快與k8s的分手歷程
近期,Docker 公司更新了旗下產品的訂閱策略,其中最顯著的變化是Docker Desktop條款的修改。Docker Desktop 對於同時滿足僱員少於 250 人,年收入少於 1000 萬美元的小型企業、個人、教育和非商業性開源專案仍然免費。但是大中型企業則需要它需要付費了,價格每個使用者每月 5 美元起。
雖然收費條款有5個月的寬限,但是而對不斷商業化的Docker,開源替代產品也開始躍躍欲試,比如像Podman UI、lima都是不錯的選擇。而最令人唏噓的是Docker這樣一位開源界的三好學生,為什麼會有如此之大的轉變。
天下武功唯快不破,在雲計算的江湖從虛擬機器到容器,再到Serverless莫不如此。十年前OpenStack的釋出讓雲計算正式進入了虛擬機器的IaaS時代,OpenStack憑藉其開源、開放的特性,使得私有云的建立門檻大幅度降低,理論上講任何掌握了OpenStack開發能力的企業都可以自行建立和提供雲計算服務。
當時的雲計算,本質上都是基於虛擬機器的,OpenStack可以將一些效能強勁的物理伺服器,拆分成若干個虛擬機器,提供給使用者使用,但虛擬機器還是太重了。即使是飛天叢集,新增部署虛擬機器的時間也是以分鐘來計的。但是網際網路上的機會往往轉瞬即逝,分鐘級的等待對於使用者來講就是不能忍受的煎熬,因此瘦身版的虛擬機器也就是容器開始走入了大家的視野。
通俗的講,容器就是基建狂魔版的雲平臺,雖然傳統的基建技術安全性更高,穩定性也更好,但是從頭修路、蓋房、裝修成本太高時間也太長,而容器本質上是一個最小執行環境的映象,只要給點陽光就能野蠻生長,而且用完以後想拆也很方便,是應對雲時代流量衝擊的神器。目前Docker幾乎已經成了容器的代名詞,每個網民都接受過由Docker提供的服務,IT人在日常工作中肯定都接觸過Docker,Docker作為容器技術的始祖,以一個憨態可掬的小鯨魚形象出現,在剛剛出場之際就將Vmware旗下的Paas平臺-Cloud Foundry斬於馬下。
2013年開始,雲計算的PaaS大幕開啟。在PaaS時代,雲計算的最小使用單位從虛擬機器變成容器。最早出現流行開來的PaaS平臺是由Vmware創立的CloudFoundry。2012年在帕特.基辛格正式接手Vmware以後,就開始在PaaS方向發力,Cloud Foundry正是基辛格親手打造出來的拳頭產品,透過應用託管功能。開發者只需要透過一條簡單的命令,就可以將整個專案打包,上傳到Cloud Foundry,而Cloud foundry主機叢集中,找到滿足使用者需求鶴機,透過容器化技術,解壓並執行使用者的專案包,並快速對外提供服務。令人感嘆的是歷史總是這樣的對稱美,Cloud Foundry在被Docker打敗之後,基辛格迴歸英特爾推出的首款拳頭產品至強三代Ice Lake有一款專門針對docker的增加型號-8352v,這個型號在高密度容器部署方面有奇效,這段往事讀者可以參考前文《溢價5倍欲將Sifive收入麾下,英特爾的絕地反擊戰》、《超異構時代“鍊金術”,開發者表示“驚豔”》這裡不加贅述了。
除了基本的容器功能以外,Cloud Foundry還提供應用分發、監控,標準化災備體系等等服務,Cloud Foundry將程式設計師從繁重的運維任務中解放出來,讓開發者不需要再去關心執行平臺的資源使用狀況。但是Cloud Foundry並沒有把工作做到極致, 其打包功能一直為外界所詬病。開發者甚至要為每個應用版本應用打一個包,其帶來的除錯成本之高令人咋舌,甚至有人抱怨在Cloud Foundry所花費的除錯時間遠遠高於開發一款新的應用。
Build once,Run anywhere這句響亮的口號就是Docker打敗Cloud Foundry的最大秘決, Docker與Cloud Foundry相比其底層技術都是namespace和cgroups,但是Docker很好的考慮了應用打包的一致性與複用性問題,並提出了映象這種創新式的解決方案,完全可以做到三分鐘部署一個Nginx叢集的效果,正是這種對程式設計師的友好特性,讓Docker成功取代Cloud Foundry成為當之無愧的C位。
Docker成為C位後,巨頭們也看到了容器方面的商機,CoreOS推出了Rocket容器,Google也推出了lmctfy容器,但是面對簡潔易用的Docker,即便是開源界無往不利的Google也敗下陣來,推出不久之後lmctfy容器專案就被關停,幸福來得太快也讓Docker有點飄了,在得到大筆融資之後Docker公司開始了瘋狂的買買買,不過Docker之前一直是靠開源社群的力量發展壯大的,靠收購打造出的容器三件套:DockerCompose、Docker Swarm以及DockerMachine明顯有點水土不服。不過這倒是影響不大,在有了容器三件套之後Docker正式把公司的名字由原來的dotCloud改名為Docker,並且將Docker註冊成了商標全面開啟商業化之路。
這一系列的動作基本宣告了之前的開源少年已經開始了商業化的轉身,這也就意味著,未來雲廠商要容器就要向Docker公司支付授權費用,這一系列的動作讓容器領域的眾多玩家對於Docker產生了警惕,過舊暴露的商業化意圖,讓雲廠商們感到自身利益受到威脅,Docker沒落的種子就此埋下。
2015年,Docker在同行巨大的壓力下,他們牽頭成立了OCI(Open Container Initiative)基金會,並將自己的容器執行時LibContainer改名為RunC捐贈給OCI,由OCI與容器各方共同制定容器和映象的標準和規範。但是當時的Docker基本沒怎麼把OCI放在眼裡,而且憑藉自身的使用者優勢對於對於標準的制定也是漠不關心。現在回顧起來放棄標準制訂的話語權,也是後來K8S有勇氣和Docker說再見的主要原因,雖然OCI在Docker的缺位下發展緩慢,但接下來出場的CNCF(Cloud Native Computing Foundation)基金會卻是個真正的狠角色,隨著CNCF的出現,Kubernetes也就是K8S終於登場了。
K8S是Google在2014開源的一款容器編排專案,一開始K8S只算是一個Google一個人參與的獨角戲,但CNCF帶來的社群力量改變了這一切,由於這個時候Docker已經在商業化的道路上一去不返了,不久以後K8S社群就開始和Docker分庭抗禮了,而且逐漸有後來者居上的趨勢,基於K8S的微服務等新興技術框架迅速流行開來,最終使得以K8S為代表的容器編排平臺成為了雲原生時代的C位。面對CNCF的迅速發展壯大,Docker不得已將自己的Containerd捐贈給了CNCF,並且在2017年10月在Docker企業版中預設內建K8S平臺。
如果說Docker打敗Cloud Foundry依靠的是簡潔、簡單的微創新,那麼K8S對於Docker就是降維打擊了,Docker Swarm編排工作只是站在容器視角處理問題,而站在K8S的角度上,容器只是一個執行時的環境,Pod和Service才是K8S編排建模中所考慮的重點,只要符合標準的容器執行時都可以做為Pod進行編排,也就是說K8S對於所有容器一視同仁,使用者是否用Docker根本無所謂。在取得優勢身位以後,K8S果斷開始了去Docker化的動作,在去年年底,CNCF官宣在K8S的1.20版本中Docker能夠正常使用,但是會有警告提示,而1.22版本以後,則移除Docker的支援。這其中最大的影響那些用到Docker API的應用都將不能在K8S平臺上運行了。
正如剛剛所說Docker在如日中天的時候對於執行時的標準漠不關心,這也使得很多Docker的增強功能是由Docker Shim元件提供的專屬API來完成的,但是Docker Shim並不屬於標準的容器執行時,這也就意味著K8S甩掉Docker時根本沒有什麼太大的負擔,而且Docker目前在商業化道路上與CNCF社群漸行漸遠,K8S目前作為雲原生時代的C位,完全沒必要為企業版的Docker去背書。
目前DockerDesktop企業版收費的做法並不是一個明智之舉,以目前Docker的江湖地位,各種開源替代產品比比皆是,商業化的動作只會加快他們與開源社群的分手歷程。不過拿了人的總是手短,接受融資就要受制於資本,Docker的歷程在開源界也算典型,比如Red Hat在被IBM收購以後就停掉了免費版的Cent OS專案,如何平衡免費、開放的理念與商業化利益之間的關係,是整個IT界都需要仔細考慮的問題。
作者:馬超,CSDN部落格專家,阿里雲MVP、華為雲MVP,華為2020年技術社群開發者之星。