容器和IaaS：誰動了誰的奶酪 ?
【編者的話】此次主要分享一下ZStack對IaaS和Container之間關系的一些思考。
很高興今天能在這里跟大家一起分享一下ZStack對IaaS和Container之間關系的一些思考，我先簡單介紹一下我接觸容器技術的一些背景。
2013年的時候，我還在Citrix工作，有一天梁勝和我們的架構師Chairdeep找到我，說有一個客戶需要用到容器，讓我調研一下，當時這個客戶主要需求是要做HPC，即高性能計算，傳統虛擬技術性能損耗比較大，用Bare Metal技術又失去了虛擬化的靈活性，所以我們決定用容器方案，比如在一個機器上只跑一個容器，這樣這個虛機就可以獲得近乎物理機的性能，同時具有所有虛擬化的靈活性。
最初我選擇的方向是LXC，因為這個技術我本身比較了解，也是比較流行的技術，我花了幾天時間就把POC做好了。正好這個時候公司來了個新同事叫 Susan，她以前是DotCloud的銷售人員，知道我在做這個事情，建議我試試Docker。于是我又開始研究Docker，感覺是這個新生事物很多理念都非常新，但客戶的需求是傳統虛機用法，似乎那時的Docker并沒有帶來特別多的好處，而且Docker Hub的用法，CloudStack里secondary storage并不能很好的支持，所以最后我們還是采用了LXC的方案。我在做好POC后，就交給印度團隊去實現了。也是從那個時候我開始了解并認識容器技術。
從這個背景，就可以看出我個人對IaaS和容器技術的關系，簡而言之，容器和IaaS將來誰動誰的奶酪，不取決于兩者自身，而是取決于用戶如何使用容器技術。
大家都知道，Docker可以火起來，并非是它使用了輕量級的虛擬化技術，這個技術LXC早就有了。而是它提倡了一種新的構建App- Centric應用的方式。這個方式區別于我們傳統的集中式架構的應用設計，以微服務為核心，構造一種新型的分布式應用集群。這是互聯網公司非常需要和喜歡的，也是廣大DevOps人員喜歡的。所以在很長一段時間，從我們做IaaS開發者的角度來看，容器技術更偏向于PaaS，做的是PaaS層面的事情，跟我們是井水不犯河水的。
但近一兩年容器技術的快速發展，各種容器編排系統的出現。讓IaaS從業人員產生了一種危機感。即容器越來越模糊了PaaS和IaaS的界限，很多容器編排系統其實已經在做IaaS的事情。那么是不是有一天IaaS會完全被容器取代，我們的奶酪被容器動了?
ZStack出來之后，很多朋友都在問我們什么時候支持容器，包括我的前老板梁勝，大家知道他創建的Rancher是做容器的，也建議我轉做容器。但我們卻遲遲沒有動作，很多朋友都很急，說IaaS早就過氣了，現在容器才是風口，你做容器無論是在融資還是講故事，都比IaaS好多了。但從我個人的角度來說，我始終認為容器最強大的地方在于它帶來構建應用理念的變化，應該是做App-Centric的編排系統，如果傳統IaaS要往這個方向做，需要做出的改變還是挺多的。如果僅僅是像OpenStack里nova-docker那樣做，對于ZStack來說就是一個星期的工作量，但這種虛機的用法，不應該是容器的主流，當時我是這么認為的。
但近半年來，我跟不少互聯網公司用容器的朋友聊過，也看過像京東、360的同行關于容器使用的分享，我驚奇的發現似乎將容器當做虛機用似乎已經開始流行起來，并非我之前想象的大家會基于容器技術重新構建應用。這個時候我感覺到，或許將來真正的情況是，IaaS會動了容器的奶酪。
一項技術的流行和普及，最初都是從技術圈子里散播開來，技術的發起者或許有著非常遠大的抱付和初衷，但用戶使用這項技術的現實可能并不是想象那樣。用戶總是會找到最適合自身業務的方法來使用新技術。容器也是如此。因為大部分運維人員和開發人員，最熟悉的還是以虛機的方式構建應用，當容器帶來了更快、密度更高，更輕量級的虛擬化技術時，大量的存量系統還是以他們最熟悉的方式，就是虛機方式來使用容器技術。這個現實，為傳統IaaS帶來了巨大的機會。
因為虛機用法的編排系統，是傳統IaaS最擅長的。一旦用戶用腳投票，最終讓容器虛機用法流行開來，目前的各種容器編排系統相對于IaaS來說就沒有任何優勢。因為IaaS是最了解計算、存儲、網絡子系統的，容器僅僅是計算部分的一個分支而已。容器的編排系統如果要做IaaS的事情，就會越做越重，也就是把IaaS的事情重做一次，世界就不那么美好了。
前幾天在另外一個群，DaoCloud的CEO羅比也談到了容器和IaaS的關系看法，他認為大家最好的情況是一對好基友，井水不犯河水。我也覺得這是最好的方式，容器做PaaS層的事情，跟IaaS層無縫配合一起構建出生態。但如果一旦容器虛機化在生產環境流行起來，那么IaaS一定會犯這個河水，踏入容器的領域。
但從另一個方面我們也要看到，App-Centric的應用仍然是所有容器從業者最希望看到的，也是他們在不懈努力的方向。激進的容器擁護者聲稱容器多進程、SSH的使用都是落后的應用方式，不是原生的容器應用，倡導大家要圍繞容器構建出新型的應用。這個其實是我們IaaS從業者很希望看到的。因為IaaS本身提供的功能離用戶的最終業務還是太遠，我們非常需要有一個層面，把IaaS和用戶的業務粘合起來。從目前來看，我認為容器是最好的選擇。我們希望看到有一個標準的容器層，能夠適配不同的IaaS，為用戶打包、分發、管理、監控、運維自己的業務。這樣IaaS可以專注做IaaS的東西，而不是大包大攬什么都做。這是最理想的生態關系。
未來的現實如何我們現在很難預料，因為容器技術仍然處于Hype Cycle的上升期。雖然互聯網公司已經有不少成功案例，例如Netflix，但大家知道互聯網公司的很多技術都是屠龍術，不是廣大傳統企業能玩轉的。所以最終容器技術的落地情況如何，還是要看如何擁抱傳統應用。未來雖然有可能屬于App-Centric的容器時代，但也可能是被現實拖回傳統的虛機方式。這里面的關鍵，還是在于用戶如何去使用這個技術，在于用戶如何用腳投票。
所以今天這個話題《IaaS和容器：誰動了誰的奶酪》，我的觀點可以概括為：如果將來流行的容器用法仍然是虛機方式，那么IaaS一定會動容器的奶酪;如未來屬于App-Centric，那么IaaS跟容器屬于相互依賴的健康生態，共同構建用戶數據中心的新形態。容器我個人認為是比較難動IaaS的奶酪的，因為存儲、網絡這些部分是繞不開的，如果容器編排系統選擇向下發展，那么只會陷入另一個IaaS的泥沼，這些是他們不擅長的。但有一種情況是可能的，就是用戶的容器部署只需要一個輕量級的IaaS，那么這個時候重量級的IaaS就會變的很尷尬，可能被容器使用者拋棄。這個也是ZStack這樣輕量級IaaS的機會，我個人認為輕量級的IaaS + App-Centric的容器集群，會是未來廣大容器用戶喜歡可看到的方式。IaaS在容器時代仍然是充滿機會和大有可為的。
Q&A
Q：容器當做虛機，CloudFoundry現在能很好的支持Docker Hub的用法嗎，如何做到的?
A：很抱歉我不是容器的專家，對各個容器編排系統了解也有限。第一個問題我無法回答，因為我沒有研究過CloudFoundry 對Docker Hub是如何支持的。但從技術上來說，IaaS支持Docker Hub沒有技術障礙。我以大家熟悉的OpenStack舉例，Glance完全被Docker Hub做成一個后端，用戶無需上傳image，只要輸入自己的賬號，就可以瀏覽和下載image到cinder這樣的塊存儲服務。將來ZStack對 Docker Hub的支持也是這個思路，即把Docker Hub做成我們的backup storage的一個后端插件。
Q：『Mesos是在大規模集群生產環境中運行Docker的黃金搭檔?！粚@句話你的看法是?你提到的容器編排系統，是否指Mesos，還是指Docker Swarm或Kubernetes?
A：我指的容器編排系統主要就是k8s、Mesos、Rancher這些。他們的主要方向還是奔著App-Centric去的。至于誰是Docker的黃金搭檔我不知道，我感覺每家都說自己是最佳選擇和黃金搭檔。當然這是因為他們對我國的新廣告法不太了解。
Q：容器適配不同的IaaS：容器是對操作系統的虛擬化，對網絡、計算、存儲的適配是操作系統的基本功能，容器適配不同的IaaS應該自然就有的功能吧?
A：容器適配IaaS主要是指容器的編排系統可以通過IaaS的API去獲取自己需要的計算、網絡、存儲的資源。例如通過 IaaS的API去創建虛機，拿到虛機的IP地址去部署容器;又例如使用創建私有網絡等功能。好的IaaS必定是提供全API給容器編排系統使用的。這樣容器編排系統可以專注往上做，做DevOps的功能，而不是把精力浪費在管理存儲、網絡這些它自己不刪除的東西。比如說容器編排系統去編程硬件交換機配置網絡，我認為就是方向走偏了，是在做IaaS的東西。
Q：能不能詳細點解釋一下App-Centric是什么樣的?
A：App-Centric要解釋清楚比較難，這個跟Microservices、Cloud-Native Apps一樣。要用簡單的幾句話解釋清楚是比較難的。我個人簡單理解是，App-Centric的編排系統的核心是應用的的部署、管理、發布、持續集成，一切功能以應用為中心設計。如果編排系統的核心是管理計算、存儲、網絡的硬件資源，那這個是iaas的編排系統，就不是App-Centric的。
Q：問一下輕量級的IaaS，除了ZStack還有哪個比較成熟?
A：我當然想說是ZStack。我看到后面有幾個關于問ZStack的問題，為了避免在這次分享上打廣告，我就不詳細講了。歡迎大家訪問我們的網站zstack.org/cn，我們有16篇技術文章講我們的不同和優勢。另外關于跟OpenStack和CloudStack的對比，大家百度一下ZStack、OpenStack、CloudStack就可以搜到幾篇業內人士寫的對比文章。
Q：雖然有京東和360案例，但你支持把容器當虛擬機使用嗎，為什么?很多人曾經很質疑這種方案，包括我也反對。
A：這個問題很難說支持和不支持，我剛才也說了，技術人員有自己的情懷和初衷，但市場是用腳投票的。用戶選擇了這樣的方式一定有他自己的理由，沒有對錯之分。運維人員有一句話叫沒有絕對好的技術，只有最適合的技術。其實很容易理解為啥大家會把容器當虛機用，因為已有的存量系統都是基于虛機設計的，要為了容器的出現而重寫業務系統，我認為除非有巨大的痛點，否則很少有公司會主動去這么做。當然，很多新興互聯網公司，在沒有歷史包袱的情況下，我非常贊同以新的方式去構建業務系統，但這也不是那么容易的。借Netflix 團隊的一句話說：你看到了我們現在微服務做的這么好，是因為我沒告訴我們填過多少坑。
Q：請問 IaaS+APP是怎樣的一個架構呢，在您最后一段分享里”因為大部分運維人員和開發人員，最熟悉的還是以虛機的方式構建應用，當容器帶來了更快、密度更高，更輕量級的虛擬化技術時，大量的存量系統還是以他們最熟悉的方式，就是虛機方式來使用容器技術。這個現實，為傳統IaaS帶來了巨大的機會。“，可以簡單介紹下“為傳統IaaS帶來了巨大的機會”中有哪些機會嗎?
A：這個巨大的機會就是讓我們反思大而重的IaaS系統到底是不是客戶所需要的，IaaS系統自身是否需要做減法做虛擬化+。因為我們看到使用容器的很多公司，他們沒有SDN，沒有分布式存儲，一樣把業務搬遷到容器上了，運行的很好。那么現在大而重IaaS系統設計，是不是路走偏了，我們是不是能夠把IaaS簡化，提供最方便、最可靠、最容易的方式讓容器使用IaaS，而不是讓容器因為IaaS的大而重拒絕IaaS而自己去做 IaaS的功能。
林帆：容器和虛擬機本質上只是實現虛擬化的兩種方式，一開始初衷不同，之后由于用戶習慣而產生一些交叉，最終而言容器的應用場景還是會趨于 PaaS化的。沒記錯的話，在京東和360的例子里，是先經過了Docker做虛擬機這樣的過渡時期吧，但最終的目標同樣是真正將容器的分布式調度、編排的優勢發揮出來，也就是走向類似PaaS的方向。
Q：我的理解是容器做虛擬機使用這個過程更多的存在于產品底子已經比較重的企業，很多互聯網企業會直接從容器的PaaS模式開始，不知道你怎么看這個觀點?
從Nova-Docker和其他一批試圖把Docker做成IaaS用項目現在不冷不熱，和Mesos、Kubernetes社區繁榮的情況來看，Docker做IaaS只能算是一個容器過渡期的現象吧。并且，ZStack會打算基于IaaS推出服務編排這樣的功能嗎?
A：nova-docker不熱是正常的，因為這種虛機用法不是容器社區的主流。k8s、Mesos是主流。但大家要認識到開發者圈子里的熱并不代表市場熱，技術圈是一個最容易自high的群體。當Hype Cycle過渡到谷底時大家才能看清楚到底市場需要的是什么技術。ZStack目前沒有計劃推出k8s這樣的編排系統功能，技術上不是問題，我們的架構是編排系統的通用設計，用同行的評價說你們去做12306都沒問題。我們的主要的考慮是要專注，當一個軟件號稱什么都能做，什么功能都有的時候，通常意味著它什么都做不好，用戶也會搞不清楚這個軟件到底要解決什么問題。但我們之后一定會推出虛擬機用法的容器集成，這個對我們來說非常簡單，而且也看到很多用戶在這樣用了，所以我們一定會去做。
Q：怎么理解什么是輕量級的IaaS，和現在的會有哪些變化和區別?
A：這個前面一個問題談到了。即現在大而重的IaaS設計不一定是市場需要的。舉個例子，OpenStack在新版本里面去掉了 nova-network，部署傳統的扁平網絡也需要用neutrons，這個我認為就是重了。輕量級的IaaS就是要使用最穩定、最簡單的技術去實現用戶的使用場景。而不是期望用一種技術就能夠解決所有場景，這樣只會越做越重，越做越復雜。
Q：問一個計算的問題，我們的程序需要用到大量的GPU資源，容器理論上應該是可以和CPU/存儲一樣高效率使用的吧，有什么限制嗎?
A：理論上是可以的，CPU/存儲的使用效率即使用傳統虛擬化也已經比較高了，但IO相對于容器來說，路徑太長有性能損失。使用容器是可以很大程度上緩解這個問題，這個也是為什么我們以前HPC用一個一臺物理機一個容器的方案。
Q：你怎么看hyper.sh和clear container等超輕量級hypervisor對容器技術的影響?
A：hyper.sh、clear container解決的主要是容器的隔離性、安全性的問題。它們沒改變容器社區倡導的主流。比如hyper.sh的用法跟Docker就很類似。所以我認為他們是對容器社區的補充。當然，半個月前我也在跟Intel的虛擬化團隊溝通，建議他們做輕量級的虛機，因為我們感覺到市場對這個的需求還是很強的。
Q：ZStack跟OpenStack下的Magnum有什么相同點和區別?
A：完全沒有相同點。我們還是純IaaS，沒有為容器做特別的編排系統。
Q：因為我是HPC出身，我想問一下，算法開發繞不過去的Intel Cluster Studio怎么辦，授權怎么處理。我們在開發算法的時候需要深度依賴MKL你們是怎么處理的。另外就是GPGPU computing貌似還沒正式支持，這方面容器技術怎么處理呢?
A：我們只是提供計算資源，應用層面、業務層面是用戶自己需要解決的。我不認為容器可以幫助解決這些問題。
Q：目前ZStack有沒有什么成功案例嗎?
A：有的，我們已經有客戶使用開源版生產上線幾個月了。
Q：我的理解是容器做虛擬機使用這個過程更多的存在于產品底子已經比較重的企業，很多互聯網企業會直接從容器的PaaS模式開始，不知道你怎么看這個觀點?
A：這個取決于企業的歷史包袱多重。老牌互聯網公司的業務系統也很成熟穩定了，要完全改成容器的PaaS模式，例如容器單進程，不是用SSH，我個人覺得還是有一定難度，而且企業切換的意愿也不見得強烈，但在新業務系統里面使用PaaS的容器模式是非?？赡艿?，我也知道很多公司正在這么做。
Q：如何擺脫網絡的依賴來創建個Docker的image呢，我覺得這個是Docker用戶自己的基本權利?
A：這個基本權利我覺得還是要問GFW。 國外的開發人員是非常難理解有些他們認為跟水電一樣普及的基礎設施在某些地方還是很困難的。
Q：我認為PaaS和IaaS是不可分的，現在人為分開是有問題的，長久必然和二為一，樓主怎么看?在合二為一的前提下，也不存在容器和IaaS之爭了。
A：其實從用戶的層面來說他們是不分的，他們只關心自己的業務。但從開發人員的角度來說還是要分的，因為這個是理清楚自己軟件的界限，對軟件的架構和設計都非常重要。未來的產品可以提供IaaS和PaaS打包的產品交付給客戶，但開發自己還是要分清楚產品里面那些是IaaS的東西，哪些是PaaS的東西，否者很難做產品，做設計。
Q：真正App-Centric的是SaaS，容器編排頂多算PaaS，或者說是PaaS+IaaS(PaaS、IaaS相互依存的)，跟SaaS沒啥關系吧?
A：這個前面也回答了。編排系統的App-Centric我認為是指編排系統的核心功能是圍繞什么服務什么設計的。圍繞部署、分發、管理、運維、持續集成的應該算App-Centric的編排系統。圍繞計算、存儲、網絡的算IaaS。
Q：你認為以后的趨勢是容器只要配合輕量級別IaaS?SDN那些網絡存儲都不用考慮，那重IaaS又應用在什么場景?
A：我是指大部分用戶場景使用輕量級的IaaS+容器就足夠了。因為現在很多容器應用也沒有使用到SDN、SDS這些技術，也已經非常流行了。SDN、SDS解決了很多傳統技術的痛點，當然他們也不是銀子彈，對用戶的要求也是比較高的。所以我的看法是不能用新技術去硬套所有的場景。重的IaaS我認為適合公有云場景、大規模私有云場景的容器使用，需要用戶有較強的IT運維團隊，解決復雜環境下多租戶的容器使用問題。
===========================
以上內容根據2015年10月6日晚微信群分享內容整理。分享人張鑫，ZStack的聯合創始人，在云計算、虛擬化和軟件定義數據中心領域擁有近10年的從業經驗。2006年加入Intel從事XEN內核開發工作，為社區貢獻了QEMU E100網卡模擬器、XEN/IA64虛擬機BIOS的Windows支持等功能。2010年赴美加入Cloud.com(后被Citrix收購)，作為 CloudStack的核心工程師，參與了三星、韓國電信、SAP、花旗銀行、摩根斯坦利、英國電信等世界500強的私有云項目。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加微信：liyingjiesx，進群參與，您有想聽的話題可以給我們留言。
