容器和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运维团队，解决复杂环境下多租户的容器使用问题。
===========================