从Docker的转变，谈容器生态与微服务的发展

编者按：容器技术目前已经成为技术圈内的“常识”，但是容器生态能否健康发展仍然任重道远。在收获最初的赞扬之后，领军者 Docker 如今身陷非议：2016 年执意壮大发展 Swarm 进军编排领域，似乎 Docker 公司一方面惹毛了很多强劲的编排领域玩家，另一方面也并没有收获预料之中的成果。12月14日，Docker 计划将其关键容器运行模块之一 Containerd 贡献给开源社区。

在周晖先生看来，这意味着 Docker 的重心将回归到容器技术本身，或已放缓其在编排领域的步伐。一直从事 PaaS 和容器技术研究的周先生还认为，不管怎样，Docker 都是一家有着特色的优秀公司，Docker 成功地将容器技术理念深入人心，并且也增加了业界对 PaaS 的认识和信心。以下文章来自于 InfoQ 对 Pivotal 大中华区云计算首席架构师周晖的采访整理。

诞生与兴起：Docker 赢得声誉

容器技术被传颂并深入人心，是因为 Docker；但是，其实技术积累由来已久，早期的容器技术是 Google、IBM 等公司贡献出来的，Pivotal 也发展了 Warden 容器技术，这些公司都专注于在各自的常规业务中，并没有重点投入容器技术；而 Docker 很好地将容器技术单独形成项目产品推向社区。

为什么有同样技术潜力的公司，会有如此迥异的产品决策？我认为是因为着眼点不一样或者说基因不同，大公司着眼于规模化的企业应用，比如 Pivotal 把容器技术内置在 PaaS 技术中，然后以完整的解决方案的形式提供出来。结合自身例子来看，其实 Warden 比 Docker 早，但是 Pivotal 从成立的第一天起，就是面向企业级的，产品代码模块很完整，Warden 容器的代码量很可能少于整体 Cloud Foundry 的千分之一，单独拿出来对企业客户意义不大，并且目标客户也不需要知道那么底层的技术细节，他们需要更专注于业务创新。

而 Docker 公司具有开发者基因：Docker 的产品很适合开发者，快速升级以满足新的功能需求，完全不用管和前面版本的兼容性，就像有故障重启 Windows 那么简单，但是你让客户去重启他们生产系统的 Linux 就不会那么轻易了，并且 Docker 对开发者简单易用。Cloud Foundry 提供的容器是黑盒子，对运维人员来说简单易用，无需关注容器细节，甚至都不需要直接操作容器；而 Docker 是白盒子，随意增添组合特性，对于技术fans 很有价值。同样 Docker 也有很多很棒的设计，举例说明，镜像仓库，谁都可以把自己做好的 Docker 镜像上传上去，目前Docker的镜像仓库有海量的镜像，这符合互联网的分享精神并因此发展壮大。所以 Docker 之所以发展起来，可以说他摸到了市场的脉络。

因此除了自身优秀和容器界技术成熟之外，另外一个因素是 Docker 生逢其时。2013年Docker 诞生之时，正值企业应用转向互联网应用高速发展时期，应用小型化微服务化的需求正好是其用武之地，也就是适应了今天流行面更广的微服务的一个方面---应用部署到容器中运行。

变形发展：急于盈利，引起生态圈的利益冲突

Docker 在2016这一年做了让生态圈反感的事情：通过之前收购一些公司大张旗鼓地发展 Swarm，集中发力集群编排管理。

容器生态中有两个领域：一类是容器本身的领域，另外一类编排集群管理领域。这两个领域虽然会有重叠的部分不完全独立，但是基本上各有各的发展方向，靶向用户不同。

第一领域是 Docker 最开始在做的内容，面向开发者、小型企业或者个人版尝试测试，直接应用在大型企业中的还是比较少，最多是一个部门级别的应用（数量级一般为个位数）；用于开发和测试，在生产中用的比较少（设计时也没有考虑到生产的复杂性）。

第二领域的领军代表是 Mesos、Kubernetes 和 Cloud Foundry，或者说现在的 CaaS。在企业中的应用，这个派系更适合做成云，管理的是大规模的应用运行生产环境。

两者的定位是不一样的，但是第二类集群管理具有更多、更早的盈利空间；经过多轮融资后的 Docker 对盈利愿望比较强烈，因为容器本身开源很难挣钱，都是不掏钱的客户，所以希望打入企业级的容器集群管理市场来盈利。可是 Swarm 等一系列举动被视为捆绑竞争，非但没有让人对其技术刮目相看，反而损还他与生态圈内其他厂商的关系。在今年7月底，Google Kubernetes 布道师 Kelsey Hightower 和 Docker的 CTO Solomon Hykes在 Twitter 上发生了激烈争论，争论的主题是要不要用 RunC 或其他容器来取代 Docker 引擎以及 OCI 的意义。

被迫妥协：共同研发的 RunC 意味着什么？

Docker 一开始就一家独大，并且并不是一种开放的态姿态在做，所以很早之前 Google 就投资了 CoreOS 来做竞争的容器--Rocket。那时是三家鼎立：Docker/Rocket/Warden，为了避免惨烈的竞争，大家终于统一意见，决定成立 OCI 做统一的容器运行时---RunC，OCI 成立后加入了大约50家厂商。出于对 Docker 封闭化商业式发展的担心，OCI 商讨出这种方案：以 RunC 为核心重新构建生态圈，并且通过插件来弱化容器在 CaaS 生态圈的重要性。

OCI 负责的 RunC 是非常小的运行核，其目的在于提供一个干净简单的运行环境，他就是负责隔离 CPU、内存、网络等形成一个运行环境，可以看作一个小的操作系统：现在 OCI 只负责这些，尚未扩大到更大的范围，其实这样是小而美的，这样的是业界所最需要的。

当然， RunC 的生态发展就会局限在企业级别应用中，并因此具有不同的发展目标：RunC 不是要提供多少种工具，而是要非常稳定。 接下来需要做的是可能是添加完善一些功能，比如将 Docker 镜像导进来，与各种插件更好地结合（动态化即插即用），热启动和迁移。这些功能是企业需要的，但是对开发者没什么作用。以热迁移为例，从一台虚拟机迁移到另外一台虚拟机，但是开发者可能本来就一台机器并没有这个需要。

因为 RunC 是 Docker 的一个子集，所以单纯从代码量上来讲，RunC 只占 Docker 的百分之几。相比而言，Docker 有丰富工具，更贴近于开发者。这也是为什么很多个人开发者并不知道 RunC，因为RunC的使用者都是 Mesos、K8S 和 Cloud Foundry 这类 CaaS 厂商。

在 RunC 早期，Docker 是主要贡献者（在我看来，如果 Docker 不参与 RunC 的发展就意味着和容器生态圈决裂）；后来随着各大厂商对 RunC 大幅贡献代码，RunC 的代码贡献者越来越多样化，Docker 所占比例在持续下降。通过不断迭代，RunC 一定会越来越成熟，它已经在生产环境中开始积累技术了，Cloud Foundry 已经有不少全球重量级客户在用内置 RunC 容器，经历的很多坑的 bug 修补已经回馈到 RunC 源码中去了。

Docker 的运行内核虽然是从 1.11 支持 RunC 的，但是 Docker 的心态是很复杂的：一方面作为 OCI 成员必须支持 RunC，但是另一方面他会担心 RunC 对 Docker 的替代的威胁。

危机解读： 适合Docker公司的路在何方？

坦率而言，我认为 Docker 进军编排界并没有优势，因为他缺乏企业级基因。

Docker 更适合在容器本身的技术，今年 Docker 力推 Swarm，把资源花在了集群管理上，这其实并不是 Docker 技术的初心。当时 Docker 迅速流行是因为简单易用，而后来走却想把太多东西塞到 Docker 中。

在从目前适用场景选择来看，一般而言，使用 Docker Swarm 的都是小企业的小规模应用，而大企业采用的都是 Mesos、K8S 或 Cloud Foundry。（当然有极少的案例采用了 Docker 的 Swarm，但是从比例而言这并不具普遍性）。因为最初的设计来源就不一样，前者是从开发者角度设计，而 Mesos、K8S 和 Cloud Foundry 是从企业中来，有很多企业运维的实战积累。

Docker 也就是小几百人的公司，并不算巨头公司，做企业级市场比较吃力，而做中小企业或是个人用户市场这种思路更适合 Docker 的盈利模式。在我看来，不论国内国外，做企业级市场一定需要很多销售去和企业用户打交道聊需求，项目实施的时候往往要根据客户的需求做定制，要知道每个企业用户的需求是不一样的，没有办法进行完全统一的标准化，那定制化的需求就需要一定规模的人力投入，每个项目都需要一定的人员资源投入，小公司很难做这种投入。在我看来，小作坊做企业用户还是面临很大的挑战。

从企业级需求来看，比如企业一个考虑就是，一定要前后版本兼容，否则就无法升级。而这恰恰是 Docker 不 care，比如个人用户可以随时重启机器，开发者在遇到问题可以重启，在企业级的思路不是这样的。Docker 的思路并不是做企业级 IT 应用系统的思路，所以如果应用到企业级应用中一定会遇到问题。至于很多互联网公司在应用 Docker，很多互联网公司也是在摸索，包括自己做 Docker 集群管理的不少，但自己做 Docker 集群管理的基本都开始开始转向 K8s、Cloud Foundry、Mesos 这些专业的容器集群管理软件了，这是很明显的趋势，那么这些互联网企业当初花资源做的集群管理基本就是被废弃，即使现在没转的迟早要转型到 CF(Cloud Foundry) / K8s / Mesos。对于企业客户来说，这种试错是得不偿失的，因为企业客户没有这么多人去研究开发容器集群管理软件。但对互联网公司来说，这个试错是可以接受的，毕竟养这么多工程师其中有一部分就是通过不断的、或大或小的试错而优化技术的。

Docker 为什么最初发展那么快，因为是面向开发者，个人用户或者中小企业，这是他兴旺起来的市场。起步于个人消费者市场，却又想立刻切入企业级市场必然会有很多水土不服，这种背离最初的起源的做法并不是很明智，我认为面向个人消费者其实才是 Docker 的固有基因。

那怎样才是 Docker 更好的盈利模式呢？在我看来，Docker 可以在镜像仓库上发力，做成类似苹果 AppStore 的模式。Docker的优势在于他有镜像的入口(互联网最关注的几个价值点之一)，他应该把镜像市场运营好，第三方在使用镜像的时候进行付费。比如 MySQL 镜像，网上不说一万种也有一千种；但是哪个镜像好用还真考验用户，如果用户用的不好，也没有反应并改进的渠道，其实这样也不利于 MySQL 镜像的持续发展，如果 Docker 能够对自己仓库市场的高质量 MySQL 镜像收费，然后分成给做 MySQL 镜像的公司，做 MySQL 镜像的公司也可以根据客户的反馈进行不断优化，做到生产可用；那么用户应该是乐意付租金费用的，毕竟自己花费成本做一个生产可用的 MySQL 镜像成本不低，这有很大的经济价值。Docker 可以与 MySQL 等厂商进行利润分成的模式扩展，就比较容易盈利了。

迷途知返：Docker 公司重拾初心？

经过激烈的碰撞，现在 Docker 又回归到自己擅长的老本行中，将视线从编排界收回到容器技术。

1、Containerd 的开源

12月13日，Docker 开源了Containerd(https://containerd.io)，它是为 RunC 提供接口并进行镜像的管理。非常有意思的是 Docker 没有把 Containerd 贡献给 Apache/Linux 之类的基金会，或是直接贡献给 RunC，而是单独开源，这个态度很是微妙，体现了对 RunC一定的防范，目前有 AWS、Google，IBM、Microsoft 和阿里云等作为初始成员，会为项目提供贡献和维护人员。 我对这个举措解读为 Docker 对容器技术的回归，并且是对16年争论的折中，他希望生态更加开放，更良性的发展，降低业界对 Docker 封闭的担心，同时也是通过 Containerd 作为桥梁，让大家更多地关注回 Docker，抵消因为生态分裂对Docker 带来的不利影响。

在我看来，这其实也不失为一种对 RunC 的堤防措施，让大家在使用 RunC 同时也不忘记 Docker；开源的举措也可以一定程度缓和关系（不过，我认为 Docker 并不会把Containerd 交给 RunC 方运营）。

2、DataCenter “钱”途未卜

今年年初的时候做了 DDC （Docker Data Center），其目的是为了向客户收费。但是，目前无法找到这个项目的营收数字，单从 DDC 和 Docker 开源部分来说，没有太大的差别，商业价值还无法确认。

3、与阿里云合作的全面合作

Docker 选择重量级的公司合作其实是一个明智的选择，虽然这对做 Docker 镜像仓库公有服务的小公司确实不是好消息。大公司的好处有人力和财力，而且 Docker 的商务版(DDC)未来要放在国内公有云上，阿里有这样的基础设施，可以在初期承受大量客户免费试用的投入，在 IaaS 公有云生产级别也更可靠。

当然，有人欢喜有人忧，此番合作还意味着：Container as a Service 公有云的市场就已经定型了，做 Docker 镜像仓库公有市场对创业公司关闭了。

4、Swarm 还会继续，但前景不明

Docker 还会把 Swarm 继续支持下去，但是编排领域的有很多细分的市场，Swarm 的发展目标应该会是小规模的集群；而且 Docker 的发展重心还是会回到容器本身，因为只有精专容器本身技术，才会凸显 Docker 独特的优势。做编排的话，从社区热度、贡献人数、发布频率可以看出，Swarm 应该是会被其他竞争对手的光环所淹没。

Docker 重新考虑在做的就是扬长避短：既然短处不能补成长处，那么就需要回归继续发扬长处。

避免竞争误入歧途，容器生态仍有蓝海

上文提到了 Docker 与阿里云合作对国内一些创业公司造成了影响。我还想谈谈我对容器创业的一些建议：首先我不认为在 Docker 之上进行定制出 CaaS 是有市场做法，创业公司如果一定要局限于 Docker 创业，可以考虑在 Docker 生态圈中，还有那些技术空白点，然后专攻一点成为特色（这是国外容器创业公司常见的做法，Docker 也收购了很多此类的优秀公司）。

那么容器生态的创业还有哪些蓝海领域呢？除了上文提到的容器类技术和编排集类，其实还有插件技术，这可以看做是两者的交集部分。插件技术是很多样化的，比如网络、存储，并且有很大的发展潜力。容器的各类插件在2017年将会有较大、较快的发展，这块目前还属于拓荒地带，经常可以看到技术进展，比如存储插件就超过10类，而且很不成熟，如果能做统一化或是成熟后、简化，都可以成为很有价值的技术。以网络插件为例，Docker 有 CNM 标准，CoreOS、Mesos、Cloud Foundry 有 CNI 标准，当然这两种标准从技术上讲还是有很多不兼容的地方，接下来的发展是兼容还是统一，还是一强一弱导致弱势方自然淘汰，需要走一步看一步。而至于存储，目前主要由很多存储厂商主导，根据自己的存储特性研发的存储插件，种类多且复杂，在何种情况下使用何种插件很考验用户对存储插件的理解能力。这些外围的插件还有较大的发展空间。

容器集群也还有很大的发展空间，集群的概念和应用集群微服务化刚刚兴起，在实际生产中会发现还有很多问题需要解决：比如功能尚不完善、可靠性和稳定性有待提高。

那插件为什么目前还不是 OCI 标准所关注的呢？OCI 目前关注的是 RunC，以一个更小的核心给业界；而插件是 RunC 补充，提供了很好扩展方式：RunC 作为运行环境，很多环境是不需要插件就可以运行，比如大部分的 Java/Web 微服务应用，反倒是传统应用容器化，需要用到插件，但这类应用并不是容器化的最主流应用,是典型的1：9现象。就是90%的容器应用不需要插件，10%的应用需要插件，但是插件带来相当大的复杂性。应用容器化只须在需要哪种功能时就使用哪种相应的插件即可。不过目前各个厂商对插件的定义和理解并不完全一样，除去共识的网络、存储等插件，其他的尚模糊。比如 Docker 对插件有自己的理解，哪些是插件，是否放到运行环境里面；Mesos 对插件的解读范围就更广，所以将插件标准化的想法在我看来还是不太容易。

但是，对于网络插件，业界认识都比较统一，因为是普遍需求，并且应用的多是VPN隧道技术。如果对这类插件进行统一标准化，可以便于相互之间的通用。

另外，为什么不建议小型创业公司考虑企业级的完整版 CaaS？和 Docker 的情况类似，这需要有企业技术经验积累、规模化人力和财力的持续投入。举个例子，在某次竞标，一家银行在招标，当时的要求就是厂商可以自我证明可以存活三年，说明企业客户对创业公司能否存活三年还是有疑虑的。

Docker兴起，加力了 PaaS 的推广

Docker 到来前，PaaS 主要在企业级市场，并不为公众所知。PaaS 分成公有云和私有云市场。国内公有 PaaS 云市场的很多厂商基本上成为了先烈，主要问题在持续投资无法实现正向现金流，因为彼时 PaaS 主要面向开发者，向开发者收费有难度，而向开发者/中小企业提供 IaaS 的市场则发展比较好。不同的是，国外最早 Heroku 、Salesforce 等在做公有云的 PaaS 比较成功，在比较长时间的实践中积累了很多 PaaS 的模型和经验，后来 Cloud Foundry 当时也吸取了当时两者很多很好的实践经验。

Docker 的流行促进了大家对 PaaS 的认知，当然也有了 CaaS 的兴起（如果进行更严格的定义的话，Docker 是属于 CaaS 的），把 PaaS 从企业级市场的认知扩展到了开发者市场。很多人是先接受并理解了Docker，才开始关注思考 PaaS。这是因为 PaaS 只是针对企业级用户，很难形成普遍的知名度；而Docker是面向开发者的，开发者使用了 Docker 之后向团队推荐，团队再向上层同步信息，是一种自下而上的传播。

私有云市场的 PaaS 最早是互联网公司在无意识的做，后来Pivotal进入市场，逐步定义了 PaaS 完整的架构，我们最早的商业客户是在 2013 年底，那时Pivotal需要向客户从 0 开始讲解私有云的概念，而现在对于技术 fans 的客户，只需要说 PaaS 是在 Docker 的基础上做了那些技术工作即可。

放眼未来，PaaS 和 CaaS 可以各自辉煌

PaaS 和 CaaS 两者有重合的部分，但是也有不同的侧重：CaaS 是提供一个容器，里面是跑应用跑数据库等都可以；而 PaaS 更关注的是应用，要对应用进行监控，要有应用框架、通用的应用功能如 Session 集中管理、日志服务、路由服务等。

PaaS 通过构建包来一键部署应用，这样的做法极大的简化了应用的安装部署，也是遵循DevOps 的理念。相反，Docker 让开发者去写复杂的脚本部署应用，比如目前DockerFile 和 Docker Compose，这对于开发者而言很痛苦乃至不可行的环节，这要求的不是业务编码技能，而是对应用服务器、对操作系统脚本的编程技能。CaaS 不限于应用平台，它也不专注于解决应用平台问题，所以它也不善于解决应用平台的问题。

和 CaaS 不同， PaaS（Heroku、Cloud Foundry等）把应用相关的复杂度屏蔽，只需一键部署应用即可运行起来，无需关注应用环境的安装环节，还有应用故障自动恢复、自动弹性伸缩、灰度发布等使得应用运维可以全自动化。回到 Docker 而言，其实它对DevOps 仍然有一定难度：Dockerfile / Compose 的书写一般是运维人员在做的事情，而Docker镜像打好了需要交给开发人员，并没有办法做的很完美，很多地方没有办法完全固定，比如开发人员发现需要更改一个应用服务器的端口这么简单的一件事情，这可能就涉及到一系列的脚本的改写，但这个事情到底是运维人员来做还是开发人员来做？运维人员来做那就不是 DevOps 了，如果开发人员来做，开发人员又很难具备运维人员的脚步编程技巧。而这一点 Heroku 和 Cloud Foundry 已经注意到了，并通过构建包彻底分离了运维人员和开发人员的分工。

我们看 PaaS / CaaS 的区别和各自的市场，PaaS 的思路基于应用平台，而 CaaS 并不限于应用平台，因此它也并不能理解应用平台的问题；所以两者面对的市场还不太一样，如果着眼于应用平台那 PaaS 比较好，如果是希望把各种资源管理起来，当做虚机使用，通过容器实现，那 CaaS 比较好。

关于 Docker 和微服务

我认为将 Docker 等同于微服务是一个误导性的看法。微服务由两个组成部分：运行环境（运行于容器中是很好的运行环境的选择），开发框架（比如服务动态注册、发现和调用等）。业内很多人只重视到了第一部分，而忽略了第二部分，比如 Docker 微服务化最常见的就是微服务的动态发现和调用则几乎完全依靠第三方平台来实现，如 ZooKeeper、Consul 等，但是这些工具的缺点是当集群达到一定量之后就会出现不稳定的问题，而且平台要适应各种代码需求有困难，我认为程序的事情归程序来解决，而不是平台。最佳实践是采用程序框架从根本上解决问题，比如 Netflix 就进行了彻底的改造，他们的服务注册、发现、治理、限流都是通过程序框架(也即后来的 Spring Cloud )来实现的，经受了大规模的应用考验。用平台解决代码层面问题是有缺陷的，因为平台解决的是平台问题，不能包揽代码的工作；代码框架是解决代码的问题：服务注册发现更适合在代码层面实现。

当然，微服务还有一个更关键的问题：如何对服务进行合理的分解和定义，不是说巨石应用随便按模块拆分就可以了。经常会有人问，微服务对业务进行升级以后多个模块如何一起部署，问这个问题就是微服务没有做好，学了微服务的形，没有学到微服务的实质，最终微服务的效果也会大打折扣。问这个问题的根源在于微服务解耦的不好，没有遵循微服务分解的方法论。如果微服务分解的好，那很大程度上是可以单独部署而不会影响其他模块。

微服务做好了以后怎么运维？故障发现、自动恢复，根据业务请求量的弹性伸缩等等这些工作，要么通过 PaaS 去自动实现，要么自主研发实现，但是这样工作量很大。最终，微服务的价值在于让开发人员只关注业务逻辑代码，不用关注非功能性相关的技术问题，这些技术问题交由微服务框架和运行环境来解决，而且微服务最终要能通过平台实现运维自动化，就是未来的热点“ NoOps ”，目前的 ServerLess，Serverless 不是目的，目标是 NoOps。前几年谈 NoOps，大家总觉得太遥远，其实 PaaS + 微服务，使得 NoOps 越来越近。

下一个技术热点： 数据微服务

容器是 2015 年最大的热点，但是 2016 年容器的热度在下降；2016 年的热点是微服务；2017 年我认为是数据的微服务化。

为何认定是技术热点？

之所以认为数据服务在 PaaS、CaaS 上的框架这个会成为新的热点，是因为：首先这个技术是微服务的延续，而且是必然的延续，微服务已经解决了运行环境—容器的问题，又解决了框架的问题— Spring  Cloud 和 Spring Boot，下一步就是数据的问题了，而且数据服务化还没有完全成熟。其实一个技术成为热点的时候就是它的对应技术方案即将成熟又未成熟之时，容器和微服务成为业界注意力中心的时候都是这样，也就是大家对它将懂未懂，最需要了解的时候，这种状态就是技术热点状态。

以今年火爆的微服务为例，SpringBoot 很早就开始有研发；2014 年以产品形式出现，但是当年月下载量是十万级别，而今年单月的下载量就可以上千万，两年不到增长百倍，这就是热点。根据数据服务化的相关开源项目在社区的反馈和贡献量来看，现在也快达到了同样的临界点。

并且，创建大数据应用仍很痛

现在做大数据应用，需要装很复杂的大数据环境。如果将其服务化，只需要点击创建即可，使用者不必关心后面的 GreenPlum、Hadoop 等是怎么安装部署的。Hadoop 那么多组件，一个个安装太麻烦了。

目前我们做的数据服务化的技术储备包括大数据服务化、数据服务化、流数据服务化，这三类技术正在逐步达到生产可用.。因为大家做完应用之后就开始考虑数据怎么办，数据按照传统方式来做是肯定没有问题的，但是应用微服务之后，要求数据要和微服务应用对应，原来的巨石应用分拆为微服务了，那原来的大一统的大型数据库，也要根据微服务进行拆分，拆分之后要分析数据是用传统的 SQL 数据库，还是新的 NoSQL，或是缓存加持久化。所以我认为这个就是将来热点。以 Spring Data 为例，它负责数据抽象，至于最后落到哪类数据库 MySQL、Oracle 甚至是 NoSQL 类的 MongoDB 的技术细节，开发者不必关心，到部署的时候再绑定，这就要求数据能够服务化。

数据服务化具体的实现可能还是先从主流互联网应用数据库(比如 MySQL， PostgreSQL)开始，然后逐渐覆盖各种实现，比如 Redis 实现、MongoDB 实现等。在解决完功能问题之后，要解决性能问题、安全问题，整个就会变成一个很大的热点；最开始还是先面向开发者慢慢扩展到企业层面。

未来之路

在最开始，业内容易把云和大数据搞混，认为 Hadoop 就是云；后来慢慢理解其实是两种泾渭分明不同的技术。而现在，大数据的进一步发展又离不开云计算能力：大数据处理最后给哪个应用使用，如何获得大数据信息价值以及提供给谁，需要经过应用平台把大数据的能力体现出去。从这个应用的角度来看，我认为大数据应用需要落在 PaaS 上。另外，云有很好的弹性能力，所以云可以更好地支持大数据的弹性计算。

不过这新结合的难度要大于之前的热点技术容器和微服务，如果说这后两者解决的是点问题，那大数据和PaaS的结合则是面的问题，PaaS本身就是个很大的面。点点结合比较容易，但是面和面结合难度就会比较大，我估计需要 3-5 年或者更长时间才能逐步发展成熟。

——————————————————————————————————－

嘉宾简介

周晖，Pivotal大中华区云计算首席架构师，有着丰富的 PaaS 云实际建设经验，负责过国内某知名银行已经生产上线一年的 PaaS 云的架构设计和部分功能的实现，参与过某超算 PaaS、某超市电商 PaaS、某电力 PaaS 等项目的建设。

生成海报

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。