云計算容器服務(wù)該何去何從
容器技術(shù)最近很火，各家項目紛紛提出自己的支持方案，比如 OpenStack、CF、Mesos，以及一堆本身就基于容器的平臺方案，更是跟容器技術(shù)脫不開關(guān)系。
這也直接導(dǎo)致了曖昧已久的 IaaS 和 PaaS 開始正面的跨界沖突。
在 IaaS 看來，做 PaaS 無非就是提供幾個應(yīng)用模板嘛，原來虛機(jī)不好做，現(xiàn)在用 Docker，瞬間給你把服務(wù)整起來。更別提還有最近出來攪局的 hyper，虛機(jī)要跟容器比性能。
而在 PaaS 看來，你 IaaS 就該老老實實地做底層物理資源給抽象出虛擬資源的事情。原來都是虛機(jī)的時候，感覺好復(fù)雜，我們搞軟件的人確實不懂?，F(xiàn)在有了一堆基于 Docker 的容器平臺，往上就都是我做軟件的人可以做的事情了，所以以后其實可以不再強(qiáng)調(diào) IaaS 了。
這些討論直接導(dǎo)致現(xiàn)在的云計算技術(shù)發(fā)展到了一個很關(guān)鍵的節(jié)骨眼上，將決定未來至少十年內(nèi)云計算產(chǎn)業(yè)的形態(tài)。
當(dāng)前狀況
姑且放下這些爭論，我們來看一下 IaaS 領(lǐng)域的 Top 開源項目 OpenStack 現(xiàn)在是怎么對待容器的。
目前有三種方案：
Nova-Docker：把容器作為虛機(jī)管起來?；旧掀渌M件都不需要動。***的問題就是容器畢竟不是虛機(jī)，比如需要提供一些額外的參數(shù)支持啦，需要引入組的概念啦，需要性能的優(yōu)化啦。
Heat Docker Driver：用 Heat 來管容器。Heat 大家都知道，是個十分靈活且強(qiáng)大的解釋引擎，理論上 Docker 需要的支持它都能有。***的問題是 Heat 畢竟是個解釋引擎，它本質(zhì)上還是要基于其它服務(wù)提供的 API。由于不是個運(yùn)維引擎，導(dǎo)致運(yùn)行時的管理沒法保障，比如自動的資源調(diào)度啊，網(wǎng)絡(luò)功能啊，等等。如果這些都做了，那就等于在更高一層上重復(fù)發(fā)明輪子了。
Magnum：玩容器的人看問題基本上都是從應(yīng)用層往上開始考慮。一幫人跑去 Nova 項目談，應(yīng)該怎么支持基于容器的 DevOps 啊，應(yīng)用模板啊，Nova 組一幫做系統(tǒng)的人就傻了，這事我們咋能干，這分明是 PaaS 該做的事情。但架不住大家都覺得 Docker 很火啊，我們肯定還是要玩點花樣的，于是一個新的項目誕生了。但玩應(yīng)用的人畢竟不懂系統(tǒng)，于是調(diào)研了下，現(xiàn)在能管理 Docker 的開源方案還真有幾個，比如 Swarm 和 Kubernetes。太好了，那么，怎么把 Swarm 和 Kubernetes 這樣的 PaaS 平臺給集成到 OpenStack 這樣的 IaaS 平臺上呢？這個聽起來好像也不懂唉，有人又想起 Heat 來了，一拍腦袋，可以先拿 Heat 來裝一套啊。每次需要的時候就調(diào)個 Heat 命令，動態(tài)的裝一套。所有問題看起來都解決了，皆大歡喜啊，真是皆大歡喜！
思考云計算
某位名人說過，之所以能看得遠(yuǎn)，是因為站在了前人的肩膀上。
讓我們拋開系統(tǒng)和應(yīng)用之爭，姑且也膽大地站在前人的肩膀上來重新發(fā)明輪子。
還是要忍不住重復(fù)，信息技術(shù)的領(lǐng)域離不開分層和抽象。在不同的時代和位置進(jìn)行分層和抽象，誕生了小型機(jī)，誕生了處理器，誕生了編程語言，誕生了 Web 服務(wù)，誕生了云計算……
拋開 IaaS，拋開 PaaS，云計算到底要提供啥？這個問題毫無疑問，是便捷服務(wù)。 于是，用戶需要操作系統(tǒng)，可以直接給你一個；用戶需要一個運(yùn)行環(huán)境，可以直接給你一個；用戶需要一套軟件，也可以直接給你一個；用戶需要一套方案，這個目前還沒法直接給你一個，屬于外包公司的業(yè)務(wù)。：）
那么，對于云平臺的設(shè)計者來說，就是要提供這些不同層次的服務(wù)給用戶，這才有了所謂的 IaaS 和 PaaS。所以，要記住，各種 XaaS 是呈獻(xiàn)給用戶的服務(wù)層次的不同，根本不是設(shè)計層次和技術(shù)方案的不同。
就好比你買了一個手機(jī)，可以玩游戲，也可以打電話。游戲和電話是手機(jī)提供給你的不同服務(wù)形態(tài)而已，并非說游戲是一種特殊的手機(jī)，電話是另外一種特殊的手機(jī)。
OK，那么，下面的問題就是討論為了滿足用戶的這些需求，在設(shè)計上該如何分層。前人的智慧是毫無疑問的，總結(jié)出了計算、存儲、網(wǎng)絡(luò)這三個根本的基礎(chǔ)業(yè)務(wù)。其中計算又是最核心和最直接的。
我們來看直接面向用戶的計算業(yè)務(wù)。數(shù)據(jù)中心里面放著的都是物理機(jī)器，物理機(jī)器上可以裝操作系統(tǒng)，操作系統(tǒng)上可以裝各種軟件，可以運(yùn)行虛擬機(jī)，可以運(yùn)行容器。無論物理機(jī)、虛擬機(jī)、容器，都是屬于計算資源。統(tǒng)統(tǒng)都應(yīng)該用云方案給實現(xiàn)供應(yīng)出來。
如果說 IDC 是讓用戶可以拿物理機(jī)作為計算資源載體，那么現(xiàn)在的云計算是更進(jìn)一步，讓用戶可以直接忽略計算資源的實際載體，無論是操作系統(tǒng)還是應(yīng)用，直接提供給你即可，無需關(guān)心具體的載體。
總之一句話，云計算就是要方便提供計算資源！
問題與方向
Magnum 目前被認(rèn)為 OpenStack 里面最有活力的容器項目，但是很可惜，一開始的路子就是偏的。
Magnum 的定位是提供一套 OpenStack API，底下可以兼容/依賴多種第三方的容器管理平臺。OpenStack 本來就是要做一套資源管理平臺，現(xiàn)在是用別人的，意味著這跟 OpenStack 其實關(guān)系不大。但是如果拋開 OpenStack，上面封裝的一套 OpenStack API 又沒有了意義。第三方的管理平臺都有自己現(xiàn)成的 API。
真正的 Container as a Service，其實應(yīng)該是在 OpenStack 中實現(xiàn)一套容器平臺，而不是在 OpenStack 中安裝了別人的一套平臺，然后進(jìn)行了 API 的封裝。
或許有人會猜測，之所以不做底下的實現(xiàn)，可能跟 Nova-Docker 有關(guān)。
如果我們只談技術(shù)，其實很容易在 Nova 中實現(xiàn)真正的 Container as a Service。在 Nova 看來，都是計算節(jié)點，但計算節(jié)點可以帶上各自的類型，比如有的計算節(jié)點是物理機(jī)、有的是虛擬機(jī)、有的是容器甚至容器組。不同的類型意味著底層不同的驅(qū)動。用一套抽象的資源調(diào)度的框架（參考 Mesos 的二層調(diào)度機(jī)制），帶上不同的底層 framework，問題很容易得到解決。
但偏偏是現(xiàn)在已經(jīng)有了 Nova-Docker，已經(jīng)有了 Magnum，不知道要經(jīng)過多少波折才可能走到這個方向上來。或許在 OpenStack 的大環(huán)境下，是一件太困難的事情了。
或許，這就是開源的魅力，分分合合，曲折中前行。
