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