2016年容器技術思考: Docker, Kubernetes, Mesos將走向何方?
2015 年自己還只是一個容器的使用者，2016 年作為容器和云相關的開發者，對容器生態圈也比較關注，本文整體從生態圈角度分析了一下當前的各容器相關產品，作為個人年度總結(本來是打算年前發的，可惜一直拖到年后了)。
- 本文只代表個人觀點，難免有遺漏的地方，還請指正。
- 本文的視角是技術生態圈角度，而不是使用和市場占有角度，也就是說該產品是以填補了技術生態圈的某個空隙而生存下來，而不是通過市場或者其他方式。
Docker
提到容器就不能不說 Docker。容器技術雖然存在了很長時間，卻因 Docker 而火。很長時間里，很多人的概念里基本 Docker 就代表容器。一次一產品經理朋友問我做什么，我說做容器相關，她表示很不懂，但說是 Docker ，她就明白了，可見 Docker 之火。這一年里，Docker 發布了幾個重要版本。我們先回顧下 Docker 本來是什么，再說它的變化。
- Docker 的鏡像機制提供了一種更高級的通用的應用制品(artifact)包，也就是大家說的集裝箱能力。原來各種操作系統或編程語言都有各自己的制品機制，Ubuntu 的 deb，RedHat 的 RPM，Java 的 JAR、WAR，各自的依賴管理，制品庫都不相同。應用從源碼打包，分發到制品庫，再部署到服務器，很難抽象出一種通用的流程和機制。而有了 Docker 的鏡像以及鏡像倉庫標準之后，這個流程終于可以標準化了。于是雨后春筍般冒出很多鏡像管理倉庫，這在以前的制品管理領域是很難想象的，以前貌似也就 Java 領域的 nexus 和 artifactory 略完備些。
- Docker 鏡像機制以及制作工具，取代了一部分 ansible/puppet 的職能，至少主機上的各種軟件棧以及依賴關系的定義和維護被容器替代，運維人員的不可變基礎設施的夢想被 Docker 實現。
- Docker 對 cgroups/namespace 機制以及網絡的封裝，使其很容易在本地模擬出多節點運行環境，方便開發人員開發調試復雜的，分布式的軟件系統。
- Docker 的 daemon 進程，取代了一部分 systemd/supervisor 這樣的系統初始化進程管理器的作用，通過 Docker 運行的服務，可以不受 systemd 管理，由 docker daemon 維護其生命周期。
前三點基本上都是容器相關或者延伸的，唯獨第四點，深受其他容器編排調度廠商的詬病。任何分布式的管理系統，都會在每個主機上安裝一個自己的 agent，由這個 agent 管理該節點上的應用進程。從這點功能上來說，和 Docker daemon 是沖突的，操作系統的 systemd，可以忽略不用就行，但要用 Docker 容器的話，離不開 Docker daemon 。設想一下，如果你老板讓你管理一個團隊，但任何管理指令都只能通過另外一個人來發出，你也會感覺不爽吧?所以 Docker 和其他容器編排調度系統的沖突從開始就種下了。感覺開始 Docker 團隊也沒思考這個問題，自己的 Swarm 也是用獨立的 agent，但后來發現有點多余，把 Swarm 的 agent 以及調度器內置到 Docker daemon 不就行?何況 Docker daemon 本身已經支持了 remote API，并且這樣設計還是一個無中心的對等節點集群模式，部署運維更方便。于是 Docker 的 1.12 內置了 Swarm(準確的說是 SwarmKit)，幾個命令就將多個單機版本的 Docker daemon 變成一個 cluster，還支持了 service 概念(多個容器實例副本的抽象)，1.13 支持了 stack 的概念(多個 service 的組合) 和 Compose(編排定義文件)，基本上一個略完備的編排調度系統已經成型。
而這個變化，也表明了和其他容器編排調度系統的決裂。本來 Docker 作為容器的一種，大家都在上面基于容器搭建編排調度系統，還能和平共處。容器相當于輪子，編排調度系統是車，結果有一天造輪子的廠商說自己的幾個輪子直接拼接起來就稱為一輛車了，造車的廠商不急才怪，這相當于發起了『降維』攻擊。
有了編排調度系統，Docker 進而推出 Store 也是順理成章。服務器端的應用大多不是單個節點或進程的應用，需要將多個服務組裝，一直以來大家都在尋找一種方式實現服務器端應用的一鍵安裝和部署。Docker 的應用打包了編排文件以及鏡像定義，配合編排調度系統提供的標準環境，再用 Store 作為應用分發，意圖已經非常明確。但感覺 Docker 這步走的略匆忙，當前編排調度系統尚未成熟，就著急推出更上一層的應用，可能會拖累后面的演進，不過這也應該是受商業化的壓力所致吧。
當然 Docker 出此決策，面臨的挑戰也是巨大的。容器生態圈的割裂，導致 Docker 得以一己之力重塑自己的生態圈。Docker 推出的容器網絡標準(libnetwork)不被其他廠商接受，其他廠商也在降低對 Docker 的依賴程度(整個后面具體分析時會提到)。Swarm 成熟度還不夠用在生產環境，它的網絡當前只支持 overlay，尚不能支持自己的網絡插件標準，編排文件的完備程度也不夠。存儲方面，去年 Docker 收購了 Infinit (很早就關注 Infinit，它一直宣稱要開源，但遲遲沒等到源碼，就聽到了它被 Docker 收購的消息)這家做分布式存儲的公司。如果 Docker 在2017年解決網絡和存儲兩個分布式系統的痛點，Swarm 的前景還是可期。
作為一個開發者，我自己其實挺喜歡 Docker 的這種設計的，雖然它推出的有點晚。這種模式符合開發團隊對容器的漸進式接納。比如開始可以先將 Docker 當做一種制品包管理工具，網絡用 host 模式，這種方式和在主機上維護部署多個應用的進程沒有區別，只是接管了依賴以及安裝包的維護。然后當開發流程的打包機制改造完畢，開發人員的習慣逐漸改變，這時候就可以引入 Docker 的網絡解決方案，先改造應用直接通過容器的網絡進行通信，但部署和調度都沿用原來的模式。等這些都改造完，運維也成熟了，然后開啟 Swarm 模式，將應用的部署和調度交給 Swarm，基本上完成了應用的容器化改造。這就像談戀愛一樣，先約約會，牽牽小手，然后(此處省略若干字)，然后才是談婚論嫁，考慮要不要做一輩子的承諾。而其他編排系統呢，一上來就要用戶回答：你準備把你的一切以及后半生交付給我了么?很多人就得猶豫了吧。
總結一下，這一年，Docker 已經不是原來的 Docker，它代表一種容器方案，一個系統軟件，也代表一個商標，一個公司，還代表一種容器編排調度系統。容器之戰剛剛開始，三足鼎立，勝負未知。但無論最后結果如何，Docker 一初創公司，從開發者工具切入，僅僅三年，火遍全球技術圈，攪動整個服務器端技術棧，進而涉足企業應用市場，攜用戶以抗巨頭，前所未有。傳統的企業市場，決策權多在不懂技術的領導，所以解決方案中對開發者是否友好，不是一個關鍵點，但從 Docker 以及國外最近的一些公司的案例(比如 slack，twilio 等)來看，這一現象正在改變，這表明了開發者群體的成熟和話語權的增加，企業應用對開發者的友好程度將成為一個競爭的關鍵點。
Kubernetes
我在 2015 年底分析 Kubernetes 架構的時候，當時 1.2 版本尚未發布。到現在已經發布了 1.6 beta 版本了。去年是 Kubernetes 爆發的一年，從社區文章以及 meetup 就可以看出來。有很多文章已經等不及開始宣布 Kubernetes 贏得了容器之戰了。
Kubernetes 的優勢是很多概念抽象非常符合理想的分布式調度系統，即便是你自己重新設計這樣一個系統，經過不斷優化和抽象，最后也會發現，不可避免的慢慢向 Kubernetes 靠近。 比如 Pod，Service，Cluster IP，ReplicationController(新的叫 ReplicaSets )，Label，以及通過 Label 自由選擇的 selector 機制，以及去年引入的 DaemonSets 和 StatefulSets。
DaemonSets 用于定義需要每個主機都部署一個，并且不需要動態遷移的服務，比如監控的服務。Swarm 中尚未引入這種概念，不過這種也可能會用另外的實現方式，比如插件機制。通過 DaemonSet 定義的服務可以理解成分調度系統的 agent 擴展插件。
StatefulSets(1.5 版本之前叫 PetSets)主要是為了解決有狀態服務部署的問題，它保證 pod 的唯一的網絡標志(主要是 pod 的 hostname，ip 是否能保持不變取決于網絡實現)的穩定性，不隨 pod 遷移重建而變化，另外支持了 PersistentVolume 規范，封裝了已有的分布式存儲以及 IaaS 云的存儲接口。
網絡方面，Kubernetes 推出 CNI(Container Network Interface) 網絡標準。這個標準比較簡單，只是約定了調用命令的參數，如果想擴展自己的實現，只需要寫個命令行工具放到系統 path 下，然后根據 CNI 調用的參數來給容器分配網絡即可，可以用任何語言實現。它和 Kubernetes 基本沒有任何耦合，所以也可以很容易被其他調度系統采用(比如 Mesos)。
從 Kubernetes 的演進可以看出，谷歌對 Kubernetes 的期望在標準制定，最核心的點是描述能力。官方文檔 What is Kubernetes? 中有這樣一段描述：
| Kubernetes is not a mere “orchestration system”; it eliminates the need for orchestration. The technical definition of “orchestration” is execution of a defined workflow: do A, then B, then C. In contrast, Kubernetes is comprised of a set of independent, composable control processes that continuously drive current state towards the provided desired state. It shouldn’t matter how you get from A to C: make it so. |
它的目標不僅僅是一個編排系統，而是提供一個規范，可以讓你來描述集群的架構，定義服務的最終狀態，它來幫助你的系統達到和維持在這個狀態。這個其實和 Puppet/Ansible 等配置管理工具的目的是一致的，只是配置管理工具只能做達到某個狀態，沒法實現維持到這個狀態(沒有動態的伸縮以及故障遷移等調度能力)，同時配置管理工具的抽象層次也比較低。它之所以選擇容器只是因為容器比較容易降低主機和應用的耦合，如果有其他技術能達到這個目的，支持下也不影響它的定位。所以 Kubernetes 去年推出 CRI (Container Runtime Interface) 容器標準，將 Kubernetes 和具體的容器實現進一步解耦，一方面是對 Docker 內嵌 Swarm 的一種反制，另外一方面也是它的目標的必然演進結果。
正因為這樣，它讓渡出了很大一部分功能給 IaaS 云(比如網絡，存儲)，也不著急推出具體的解決方案，也不著急兼容已有的各種分布式應用，發布兩年多還在專心在規范定義以及系統優化上。Kubernetes 系出名門，不擔心商業化的問題，大家閨秀不愁嫁，無需迎合別人，自然有人來適應自己。
當然理想是美好的，現實是當前已經有大量的分布式系統，重復實現了許多 Kubernetes 已經實現的功能，或者集群機制是當前的 Kubernetes 的抽象概念沒有覆蓋到的，當前將這些系統運行到 Kubernetes 還是一件很難的事情(比如 redis cluster，hadoop，etcd，zookeeper，支持主從自動切換的mysql集群等)，因為任何抽象都是以損失個性化和特殊化為代價的。這里特別說下，以前分析 Kubernetes 的時候有人反駁我這個說法，我這里不是說 Kubernetes 上不能運行 zookeeper 這樣的服務，而是很難實現一鍵部署并且自動伸縮以及配置自動變更，很多情況下還是需要手動操作接入，比如官方的這個 zookeeper 例子。
CoreOS 為了解決這個問題，推出了 operator 的概念，給不容易通過 Kubernetes 當前的抽象描述的服務(有狀態服務或者特殊的集群服務)，專門提供一個 operator，operator 通過調用 Kubernetes 的 API 來實現伸縮，恢復，升級備份等功能。這樣雖然和 Kubernetes 的聲明式理念相沖突，也無法通過 kubectl 直接操作(kubectl 有支持插件機制的提案，未來這種需求可能通過插件實現)，也但當前也是一個可行的辦法。(注：本文發布后 CoreOS 的李響對這段關于 operator 的描述進行了糾正，operator 是基于 Kubernetes 的 Third Party Resources 方式擴展的，可以通過 kubectl 操作，特此糾正)
另外，Kubernetes 在大數據方面支和 Mesos 還有差距。去年 Kubernetes 支持了 job 概念，job 生成的 pod 執行完成后立刻退出，原來的 service 可以理解成一個死循環的 job。這樣，Kubernetes 就具有了分發批量任務的能力，但還缺乏上層的應用接口。理論上，將 Hadoop 的 MapReduce 移植到 Kubernetes，用 Kubernetes 替代底層的 Yarn 的資源調度功能，也是可行的(只是開腦洞，沒有具體分析)。有個打算整合 Yarn 和 Kubernetes 的項目已經很久沒更新了，這兩者的整合我不太看好，兩個系統沖突嚴重，是互相替代的關系，不像 Mesos 和 Kubernetes 的整合(這個后面 Mesos 的段落會分析)。
部署復雜是 Kubernetes 一直被大家詬病一點。2015 年我做測試的時候，部署一套 Kubernetes 是一項很復雜的工作。去年 Kubernetes 推出了 kubeadm，很大程度的降低了部署的復雜度。當前 Kubernetes 除了 kubelet 需要直接在主機上啟動，其他的組件都可以通過 Kubernetes 自己托管，一定程度上實現了『自舉』，但易用度上和 Swarm 還是有差距。
隨著 Kubernetes 的成熟，其他廠商開始制作自己的發行版，比如 CoreOS。CoreOS 原來的容器思路應該是通過自己定制的容器操作系統，以及 etcd ，將多個 CoreOS 主機合并成一個集群，然后通過改造過的 systemd 充當 agent，上面再增加一個調度器，就可以實現容器編排調度，也是一種可行的思路，既然單機的服務進程管理可以通過 systemd，將多個機器的 systemd 連接起來不就是一個分布式的服務進程管理?但后來改變了策略，估計是這種方案采納成本太高(用戶需要同時改變自己主機的操作系統以及應用的部署習慣)，所以當前的容器策略變為了定制 Kubernetes，推出 tectonic，CoreOS 改名為 Container Linux(應該是為了避免產品和公司的名稱重疊，另外也透露出的一個信息是產品重心的變更)，專注于主機操作系統(這個后面的操作系統部分會分析到)。
總結一下，Kubernetes 經過一年快速發展，基本已經非常完備。原來的 kube-proxy 的性能問題(1.2 版本之前)，也已經解決。建議原來處于觀望狀態的用戶可以入坑了。不過在應用的最終 package 定義上，Kubernetes 尚未推出自己的解決方案，不確定這個是打算官方來搞，還是讓度給發行版廠商，不過可以預計2017年肯定會有相關方案推出。
Mesos
如果說 Kubernetes 是為了標準而生，那 Mesos 則是為了資源而生。它的理念是：
| define a minimal interface that enables efficient resource sharing across frameworks, and otherwise push control of task scheduling and execution to the frameworks |
定義一個最小化的接口來支持跨框架的資源共享，其他的調度以及執行工作都委托給框架自己來控制。
也就是說它的視角是資源視角，目標是資源共享。這個和 Kubernetes 的目標其實是一體兩面，一個從定義描述角度一個從資源角度。Mesos 其實是最早切入容器領域的，但它的容器封裝的比較簡單，只是用來做簡單的資源隔離，用戶一般沒什么感知。有了 Docker 以后，也引入了 Docker，但正如前面我分析的原因，Mesos 上的 Docker 一直有點別扭，于是 Mesos(準確的說應該是 mesosphere DC/OS) 搞了一個 Universal container，改進了 Mesos 原來的容器，支持了 Docker 的鏡像格式，這樣用戶可以在自己的開發環境中使用 Docker，但生產環境中就可以直接切換到 Mesos 自己的容器上，雖然可能有一些兼容性問題，但鏡像格式這種變化不會太快，問題在可控范圍內。
這也從另外一方面表明了 Docker 的鏡像格式基本上已經成了一個事實標準，一個容器解決方案能否切入整個生態圈的關鍵是是否支持 Docker 鏡像格式。當然 Mesos 成員對這點其實也有點抵觸，在一些分享里強調 Mesos 也支持部署其他類型的軟件包格式，比如gzip等，尤其大規模服務器的場景，從 Docker 倉庫拉取鏡像有瓶頸。這點個人不太同意，大規模服務器場景，從任何中心節點拉取任何格式的安裝包都會有問題，所以 twitter 才搞 p2p 安裝包分發，但 Docker 鏡像也可以搞成 p2p 分發的，只要有需求，肯定有人能搞出來。
容器網絡方面，原來 Mesos 的網絡解決方案就是端口映射，應用需要適應 Mesos 做修改，對應用傾入性比較強，通用性較差，所以 Mesos 支持了 Kubernetes 發起的 CNI 網絡標準，解決了這個問題。
Mesos 通過 framework 的機制，接管了當前已經存在的分布式系統的一部分職能，讓多個分布式系統共享同一個資源池變為可能，容器編排也只是 Mesos 之上的一種應用(Marathon)。這種方式的好處是讓整合復雜的分布式系統變為可能，因為 framework 是編程接口，靈活度也比較高，很多不容易跑在 Kubernetes 上的復雜應用，都可以在 Mesos 之上，比如 Hadoop 等大數據相關的系列應用。
正因為 Mesos 和 Kubernetes 的目標正好是一體兩面，然后能力也可以互補，所以很早就有人想整合 Kubernetes 和 Mesos，將 Kubernetes 跑在 Mesos 之上，這樣 Kubernetes 接管容器編排調度，替代 Marathon，Mesos 解決其他復雜的分布式應用，實現多種應用的資源共享。但 kubernetes-mesos 這個項目后來就不活躍了，一方面是 Kubernetes 變化太快，另外一方面估計是 mesosphere 發現和 Kubernetes 的競爭大于合作吧。后來 IBM 搞了個 kube-mesos-framework 放在 Kubernetes 孵化器里孵化，不過當前尚不能正式使用。個人感覺如果要真的很好整合，對 Kubernetes 和 Mesos 兩方都需要做很大改造，但這個項目對生態圈來說是一個大變數，有可能打破三足鼎立的局勢。
Mesosphere 的 DC/OS 在 Mesos 基礎上搞了一個分布式應用的 package 規范。以前的應用發布都只能發布面向單機操作系統的 package，Mesosphere 通過 Marthon，鏡像以及配置文件，定義了一套分布式的 package 規范，用戶可以通過一個命令從倉庫(repo)上部署復雜的分布式應用到 Mesos。這個和 Docker 的 Store 思路類似。
總結一下，Mesos 的優勢是可定制性強，它誕生于 twitter 這樣的互聯網公司，也比較受互聯網公司歡迎。互聯網公司的基礎設施以及系統大多是自己研發，可以通過規范來要求自己的應用適應調度系統，所以對標準化和抽象能力的的需求不如資源共享強烈。它的缺點是周邊生態比較龐雜，接口以及規范設計上，沒有 Kubernetes 那么『優雅』。
Rancher
既然容器之上的編排系統已經三足鼎立了，各有所長了，還有其他機會么?Rancher 嘗試了另外一個途徑。它自己的定義是一種 IaaS，一種基于容器的 IaaS。首先，它通過容器降低了部署成本，每個只需節點運行一個命令就能部署一套 Rancher 系統，相對于 OpenStack 這種復雜的 IaaS 來說就太容易了。其次，它自己的定位是專門運行容器編排系統的 IaaS，可以在上面一鍵部署 Kubernetes，Docker Swarm，Mesos。容器編排系統，直接運行到物理機上還是需要一些改造，并且有升級和運維困難的問題，于是 Rancher 出來了，希望抽象出一層非常薄的 IaaS 來解決這個問題。
它的思路是既然現在三家紛爭，選哪一方都是一個艱難的決定，那不如選 Rancher 好了。Rancher 一方面可以讓幾種編排系統共存，另外一方面降低了以后的切換成本，這個艱難的決定可以以后再做。
另外它也推出了自己的應用規范和應用倉庫(App Catalogs)，它的應用規范也兼容其他的容器編排系統的定義文件，相當于一個容器編排系統應用的一個超集。這樣和基礎設施相關的應用可以用 Rancher 自己的規范，和業務相關的，變化快需要動態伸縮的應用可以放到容器編排系統中，以后切換也不麻煩。
不過 Rancher 的這個產品假設的問題是，假如以后容器編排調度系統是一家獨大，那它的存在空間就會越來越小了。
容器平臺去向何方?CaaS，IaaS，PaaS，SaaS?
有人把容器服務叫做 CaaS(Container as a Service)，類似于當前 IaaS 平臺上的數據庫服務(RDB as a Service)等，是 IaaS 之上的一種新的應用服務。但個人認為 CaaS 其實是一個偽需求，用戶需要的并不是容器，從來也沒有人把 IaaS 叫做 VaaS(VM as a Service)，容器服務提供的是一種運行環境，并不是具體的服務。
容器編排調度平臺首先是一個面向開發者的的工具平臺，它上面調度的是應用，這是和當前 IaaS 最大的區別。當前的 IaaS 主要面向的是管理者，調度的是資源，所以 IaaS 的使用入口主要是控制臺，雖然有 API，但指令式的 API 使用復雜度要遠大于聲明式的 API，并且 API 的使用者也多是運維工具，很少有融入業務系統的使用場景。這是由當前 IaaS 云的歷史使命決定的。云的第一步是讓用戶把應用從自己的機房遷移到云上，只有提供可以完全模擬用戶物理機房的環境(虛擬機模擬硬件支持全功能的OS，SDN網絡，云硬盤存儲)，對應用無侵入，用戶的遷移成本才更低。
但當這一步完成時，用戶就會發現，這樣雖然省去了硬件的維護成本，但應用的開發維護成本并沒有降低，認識到自己本質的需求并不是資源，而是應用的運行環境。這個需求有點像 PaaS，但原來的 PaaS 的問題是對應用的侵入性太強，并且和開發語言綁定，能直接部署的應用有限，用戶需要的是一種更通用的 PaaS，可以叫(Generic Platform as a Service)，這個詞是我生造的，就是一種基本可以部署任何復雜應用的平臺服務，正好容器平臺可以承擔起這樣一種職責。
容器平臺雖然都有各自的歷史背景和側重點，解決方案也不一樣，但最終指向的目標卻是一致的，就是屏蔽分布式系統的資源管理細節，提供分布式應用的標準運行環境，同時定義一種分布式應用的 package，對開發者來說降低分布式系統的開發成本，對用戶來說降低分布式應用的維護成本，對廠商來說降低分布式應用的分發成本。總結一下，其實就是 DataCenter OS 或 Distributed OS。DC/OS 這個詞雖然已經被 Mesosphere 用在自己的產品上了，但個人認為它是所有容器平臺的最終目標。當然，這次容器浪潮是否能真的實現這個目標還不好說，但至少現在看來是有希望的。
于是， PaaS 會變成了 DCOS 之上的 devops 工具棧，當前很多 PaaS 平臺正向這個方向演進。而 IaaS 就變成了給 DCOS 提供運行環境的服務，DCOS 接管了上層的應用以及基礎服務。當然 IaaS 之上還有其他的 SaaS 模式的服務(由于 SaaS，PaaS 的外延并沒有精確定義，很多場景下，把面向開發者的 SaaS 模式的中間件叫做 PaaS 組件，我的理解是通過軟件實現多租戶，完全按量計費的服務都應該屬于 SaaS，比如對象存儲。這個要細說，估計需要另外一篇文章，這里就不詳細分析了)，SaaS 模式資源利用率最高，對用戶的成本最低，用戶一般不會用獨立部署的服務去替換。這樣一來，格局就變成了用戶在 IaaS 之上部署一套 DCOS，需要獨立部署的服務以及自己開發的服務都運行在 DCOS 之中，其他的能抽象成標準 SaaS 服務的中間件則優先用 IaaS 提供的。相當于 IaaS 將獨立部署的基礎設施服務，以及用戶自己的服務的部署和調度讓渡給了 DCOS。當然，最后 IaaS 本身是否會直接變成一種多租戶的 DCOS，由調度資源變成直接調度應用，也不是沒可能，但這樣調度層會面臨非常大的壓力，數據中心支撐的節點會受限，暫時看來兩層調度的可行性更大些。
這對整個 IaaS 影響很大，所以有人說對 AWS 造成威脅的可能不是 Google Cloud，而是 Kubernets(DCOS)。但即便是 DCOS 成熟，最后如何商業化還是有很大的變數。大家理想中的那個像 Apple 的 AppStore 的服務器端應用市場，最終會是由 DCOS，SaaS，還是 IaaS 服務商提供?DCOS 的優勢是掌握了標準可以定義應用規范，SaaS 服務商的優勢是直接面向最終用戶，可能占據企業應用入口，IaaS 服務商的優勢是它掌控了應用的運行環境，無論在計費模式還是反盜版上都有很大優勢。但在私有云領域，IaaS 產品會面臨 DCOS 更大的沖擊。私有云領域如果多租戶隔離的需求沒那么強烈的情況下，部署一套 DCOS 是一種更簡單高效的選擇。
容器與虛擬機之爭
從 Docker 技術成為熱門開始，容器與虛擬機的爭論就從來沒有停止過。但去年一年，大家的注意力逐漸轉移到上層，容器和虛擬機的爭論算告一段落。這個主要是因為容器本身的外延在變化。
容器，首先它不是一個技術詞匯，它是一個抽象概念。顧名思義，就是裝東西的器皿，裝什么東西呢?應用。
其實 J2EE 領域很早就使用了容器(Container)概念，J2EE 的服務器也叫做 web container 或者 application container，它的目標就是給 Java web 應用提供一種標準化的運行環境，方便開發，部署，分發，只不過這種容器是平臺綁定的。
而 Linux 容器自誕生之初，就是一組進程隔離的技術的統稱。隨著容器領域的競爭與演進，Kubernetes 的 OCI (Open Container Initiative)標準推出，Docker，Unikernels， CoreOS 的 Rocket，Mesos 的 Universal container，Hyper 的 HyperContainer(基于 VM 的容器解決方案) 等百花齊放，容器的概念逐漸清晰，我們這里可以下個定義：
| 容器就是對應用進程的一種標準化封裝，無論是采用 linux 的 cgroup namespace 技術，還是使用虛擬化 hypervisor 技術來做這種封裝，都不是關鍵，關鍵是是目標，容器是為應用標準化而生。 |
也就是說，最早，大家認為容器是和虛擬機一樣的一種隔離技術，所以會拿容器和虛擬機做比較，比較二者的隔離成本，隔離安全性，但現在容器的外延變了，和傳統虛擬機的本質差異不在于封裝技術，而在于封裝的目標，傳統虛擬機封裝的目標是操作系統，為操作系統提供虛擬化硬件環境，而容器封裝的目標是應用進程，其中內嵌的操作系統只是應用的依賴而已。
另外一方面，基于虛擬機的調度系統，比如 OpenStack，也可以將容器作為自己的調度系統的 compute_driver，也就是將容器當虛擬機使用，用來降低虛擬機的隔離成本。所以容器與虛擬機之爭本質上是調度理念之爭，而不是隔離技術之爭。
容器對操作系統的影響
Docker 沒出現之前，服務器端的操作系統基本是傳統 Linux 大廠商的天下，Ubuntu 好不容易通過自己的桌面版的優勢贏得一席之地，一個創業公司試圖進入這個領域基本是沒有機會的，但 Docker 的出現帶來了一個契機。這個契機就是一個操作系統需要考慮自己的目標是管理硬件還是管理應用。如果是管理硬件，也就是運行在物理機上的操作系統，目標就是提供內核，管理好硬件(磁盤，網絡等)，而應用層的事情交給容器，這樣硬件層的操作系統不需要考慮各種應用軟件棧的兼容問題，降低了操作系統的維護成本。如果是管理應用，那就可以放棄對硬件層的管理，專心維護軟件棧。所以這個領域能冒出幾家創業公司的產品試水：
- CoreOS 的 Container Linux 以及 Rancher 的 RancherOS 這兩個 OS 的主要目標都是接管硬件，將主機操作系統從復雜的軟件棧中解放出來，專心管理硬件和支持容器。傳統的 Linux 操作系統為維護上層軟件棧的兼容性付出了巨大的成本，發行版的一個優勢在于提供全面軟件棧的兼容性測試。而當二者解耦后，這個優勢不再，競爭的核心在于能否提供更好的支持容器以及系統和內核的升級。
- Alpine Linux 這個精簡后的 Linux 發行版則是專注于維護軟件棧，給容器內的應用提供運行環境。所以它可以做到非常小，默認只有幾M大小，即便是包含 bash 進去，也只十多M。所以 Docker 官方默認以它作為鏡像的基礎系統。
操作系統的演進和更替是一個長期的工程，基本上得伴隨著硬件的淘汰，所以至少五到十年的演進，著急不得，但可以期待。
關于技術類創業的思考
技術類創業，要思考清楚自己的機會是在市場還是在技術生態圈里占領一席之地。當然前者要比后者容易，后者最終也得變為市場的應用才能盈利，而即便是在技術生態圈中取得地位也不一定能找到商業模式，不過后者的潛力要大于前者。國內的創業一般傾向與前者，而國外則多傾向與后者，所以國內同質化的競爭比較激烈，而在差異化的生態構建方面則缺少建樹。主要是因為國內的技術積累以及普及度和國外還有差距，還屬于追隨者，只有追隨并趕超之后才會有創新，這個和 2C 領域的類似，2C 領域最近越來越少 C2C(Copy To China) 模式成功的案例了，2B 領域肯定還需要些年，不過感覺應該也不遠。
個人認為，2017 年容器編排調度領域的競爭會上升到應用層面，DCOS 之上的多語言應用框架(比如 微服務框架，Actor 模型框架)，各種已有應用和基礎設施的容器化，標準化，讓已有應用變為云原生(Cloud Native)應用，等等。
當然，理想和現實之間是有鴻溝的。一波一波的技術變革，本質上其實都是在試圖將開發和運維人員從瑣碎的，重復的，無聊的任務中解放出來，專注于有創意的領域。但變革最難變革的是人的思維方式和做事習慣，以及應對來自組織的阻礙。你說云應該就是按需的，動態的，自服務的，但用戶的運維部門就喜歡審批開發人員資源申請，于是云變成了一個虛擬機分配系統。你說資源應該動態調度，應用混合部署有利于提高資源利用率，但用戶的安全部門要求應用的業務必須分層，每層必須需要部署到獨立的服務器上，跨層調用的端口還需要申請。所以技術變革最后要落地成商業模式，首先要通過技術理念的傳播去改變用戶的思維方式以及組織體系，當然這肯定不可能是一蹴而就的，是一個長期的，反復過程，其次要等待業務需求的驅動，當業務增長導致軟件復雜度到一定規模的時候，自然會尋求新技術來解決復雜性。
結語
寫了這么多，有人會問，我還是沒能確定到底選擇哪一家合適啊?未來是不可預測的，但是可以創造的。當你做出選擇的那一刻，你希望的未來就向你靠近了一步。
本文由作者首發[高可用架構]
【本文是51CTO專欄作者“王淵命”的原創文章，轉載請聯系作者本人獲取授權】
