容器技術最近很火，各家項目紛紛提出自己的支援方案，比如 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 的大環境下，是一件太困難的事情了。
或許，這就是開源的魅力，分分合合，曲折中前行。
本文作者：yeasy
來源：51cto