Hadoop 1.0到2.0的升级成为一个重要的转折点--- Hadoop从1.0到2.0直接导致Intel的发行版出局，Intel的Hadoop部门裁撤销，Intel废弃自己的Hadoop转而直接投资CloudEra。因为Intel对Hadoop 1.0做了很多的定制、优化，这些定制优化本来一直是Intel宣称的竞争技术优势，现在1.0到2.0,立马优势变劣势，定制越多合并到新版本越难合并，而Hadoop不是Intel的主业，所以Intel权衡利弊，及时止损，放弃了自家的Hadoop，选择投资CloudEra。对Intel Hadoop客户而言，要吸取的教训是买产品一定要买卖家的核心产品，即使是大卖家，其边缘产品很容易被抛弃，受伤的是客户。这个道理其实是个大概率道理，可是吃这种亏的客户不会绝迹。
Hadoop发行版厂商面临一样的趋势潮流——留下不超过3家Hadoop发行商，其他的都会被淘汰。
再看大数据的应用和生态圈的公司，云端营销服务公司Marketo,13元的IPO价格，趁着大数据的东风，很快就飞到了45，随后熊途漫漫，在2016年2月份跌破发行价。和HortonWorks相比，Marketo是大数据的应用，是能通过大数据直接产生营收的，而且业绩也确实比Hortonworks要好，但是回天无力，持续亏损，随后被私募公司Vista Equity Partners收购。Tableau其实和Hadoop关系不大，当初接Hadoop东风股价飙起，现在也是熊途漫漫。
四、Docker的生态圈
历史不会简单的重复，但是有惊人的相似!
Docker的生态圈和Hadoop的生态圈类似。
Docker的生态圈也分为两大类，第一类就是Mesosphere\Google这类做Docker的企业运行集群管理，类似于Hadoop的发行版的厂商。第二类是做Docker的项目实施或是做Docker开发者公有云，类似于Hadoop的项目实施厂商。
Docker的流行开始于开发者，也是在开发者中传播，真正进入企业级生产系统的很少，由于Docker天生就是从开发者起家的，缺乏进入企业的基因，Docker的设计就不是运行于企业级环境下。
可是从开发者身上很难赚钱，这已经成为共识了，如果想从开发者身上赚钱，那开发者都跑路了。Docker也意识到这点，所以Docker在2016开年就提出，要进入企业级—“Ready for Production”，但是理想是理想，理想和现实之间需要跨越巨大的鸿沟。
Docker进入企业级的需求，造就了第一类的生态公司，主要就是Mesosphere\Google和Redhat三家，Mesos本来就是部署、集群管理，之前部署Hadoop大数据、批处理、ETL之类的，随着Docker东风吹来，马上支持部署、管理Docker集群，再加一个Marathon管理长周期任务,就可以实现部署应用的CaaS，虽然离PaaS还有很大距离，缺乏很多PaaS功能。
首先要深刻理解PaaS。
PaaS的P是Application Platform，是应用平台As a Service，是着眼于应用和应用平台。
很多人往往把PaaS和CaaS混淆，Container As A Service是容器即服务，只管提供容器和容器管理，并不管容器里面跑的是应用还是数据库或是数据应用，所以CaaS要弄出个编排，而PaaS并无编排一说。如果只是提供容器，和IaaS其实并没有太大的区别，只不过把应用从虚机转移到容器里来。
PaaS的设计原理和方法论是要实现应用的零运维，通过平台本身来监控应用，而不是传统的思维方式，传统的运维是要针对不同的应用去不同的监控、不同的调度、不同的故障恢复，所以运维成了救火。
PaaS通过平台本身来监控应用、监控容器、监控虚机、监控物理机，应用不用去管监控的事情，无论是应用故障、容器故障、虚机故障还是物理机故障，统统故障自动恢复，应用实现一键部署，资源实现弹性伸缩。运维的三大任务：应用和系统部署、升级，故障恢复，根据业务的资源分配，这三大任务在PaaS全自动化。
当然，要达到这个目标，你的应用要符合十二要素，要向云原生应用靠近。退一步讲，即使是传统应用，不做改造，搬到PaaS下虽然不能100%达到上述的零运维，但是也可以达到相当程度的运维自动化。
PaaS和CaaS的另外一个根本区别是，PaaS区别对待应用和服务，应用运行在容器中，实现零运维。服务就是比如数据库、消息中间件、大数据、缓存等，并不适合运行于容器中，PaaS把这些服务部署在虚机中，服务的弹性伸缩要求并不强，不像应用弹性伸缩的要求比较强，谁会去把一个mySQL或是Oracle数据库的集群在运行中弹性扩展一下?
服务没必要放在容器中，服务更多的是需要备份、调优等操作系统相关的运维，而且往往会涉及到操作系统内核的调优，而应用是往往操作系统无关了，所以放在容器中。在容器中做操作系统内核参数调优是有风险的。通过区分应用和服务，并且把应用放在容器中，服务放在虚机中，自然的消除了编排的需求。容器是个革新性的技术，但是不是任何场合都适用，作用企业应用，应当在不同的场景选择不同的技术，而不是一个技术包揽全部。