云计算年度点评2015-2016
版权声明：任何转载需全文转载并保留来源（微信公众号techculture）和该声明，并同时转载文后的二维码，否则视作侵权；如有文字或图片不全，请移步公众号techculture。
本文既是<中国IaaS产业2012年度点评>的续篇，也是《云计算时代:本质、技术、创新、战略》的内容更新，虽少了对中国市场的着墨，但尽可能将云计算行业，2015最有影响的事件，和2016最重要的行业趋势，逐一剖析。
一如既往，本文关注的不是云计算全产业链，本文关注限于IaaS和PaaS话题，PaaS也只是顺便提及，SaaS等领域跑题时才会提及。
一如既往，由于所有信息不是来源于严谨的调查和统计，也许离事实差距甚远，但仍希望读者能藉此文窥得中国和全球IPaaS之现状。如果能对中国IPaaS行业有所助益，或对相关同仁有所启发，甚或只是打发了时间，也不枉本文诞生过程中的敲敲打打。喜欢快餐的，可以直接翻过本文；对于习惯严谨数字的读者，请提前知悉本文的粗放和调侃。
一如既往，本文不从头解释基本概念和行业内的基本知识。如果你希望系统性学习云计算各个领域的基本知识，购买《云计算时代:本质、技术、创新、战略》差不多是最佳选择了。不想花钱没关系，这个公众号鸣北林的上一篇文章就是<中国IaaS产业2012年度点评>，里面没有基础知识但有历史知识。如果你真的需要了解更多，还是狠狠心买一本《云计算时代:本质、技术、创新、战略》。
不一如既往的是，本文不在区分去年总结和来年预测。年份，本就是认为划定的线线，但时间和云计算，不会按照线线来跳跃式前进，那就让总结和预测你中有我我中有你吧。
今天触发了2万字微信文章上限，删略了一些文字。
1 Openstack看起来不可阻挡，但还未等来属于自己的时代
中国想以OpenStack为生的公司么有100家，也有50家。国外的公司也不会比这少。这是OpenStack的福音，却不是OpenStack公司和用户的福音，太多的同质竞争者，太多的私有版本，而且这些竞争者和私有版本有95%将在三年内消失。这些拿OpenStack搞公有云的，根本就不清楚一点：即使OpenStack没有上述那些问题，即使OpenStack是一个开源的VMWare或开源的AWS，要做公有云，还是要自己开发。为什么？不是不告诉你，是在懒得再说，如果想不明白这个问题，就别搞IaaS了。
搞公有云搞不过AWS，大家拿OpenStack开始搞私有云。私有云那是VMWare和微软的地盘，但是现在VMWare和私有云都已经过了辉煌期，搞起来说不定容易点也未可知。
但OpenStack能否迎来自己的时代，取决于它在混合云上的作为。纯私有云不大可能是将来的主流模式，这个领域也有VMware和微软坚守。公有云市场基本没有OpenStack的空间。混合云才是OpenStack的战场。但现有的私有云项目和厂商肯定会极力抓住混合云的机会，甚至随着时间推移混合云可能走向边缘。
2016，我们将看到OpenStack是否能在搞VMware的战役中取得第一站的胜利：OpenStack能否在企业的生产环境中得到大量的部署。
2016，我们或许还看不到OpenStack迈开走向混合云的第一步。这也许需要更长的时间，毕竟搞私有云的战役才刚打响。
但OpenStack的影响力，注定要被docker超越。
2 容器和Docker：准备好迎接它的黄金时代
Docker本就和OpenStack不是一个层面，本就不应该发生争吵。但还是发生了，为什么？吃醋。Docker应用的基础技术和工具虽然是老古董，但它一出生就得到了开发者特别是DevOps、Microservice拥护者的青睐，并迅速俘获大批开发者和媒体、观察者的芳心。
Docker太流行了，太引人注目了。OpenStack支持者吃醋了。2014年8月，Linux.com和网站NewStack联合开展，从550多个调查对象那里收集了信息。关于谁是总体上最佳的开源云计算项目的问题：OpenStack、Docker、KVM、CloudStack、Ceph排名前五。但在此之后不久，通过Google的搜索量显示，Docker的热度全面超过OpenStack。
于是，有了所谓的论战。有人发出战帖：用Docker之后还需要OpenStack吗?当然可以不要。比如：叫板OpenStack:八步用Docker实现私有云。Docker当然非常适合私有云。
甚至在OpenStack峰会上最热门的主题是：Docker以及容器技术是否会替代OpenStack？这压根就是伪命题，太多假设和想当然了。无论将docker看成容器技术还是管理平台，它都与KVM和XEN这些系统虚拟化和OpenStack，不是直接替代关系。当然，间接替代是可以的，但不是必然的。
但是，这些都是Docker发展道路上的插曲。
容器是操作系统虚拟化技术，xen和kvm是系统虚拟化技术，他们在技术堆栈上处于不同的层级。Docker、Kubernets都是管理容器的工具，OpenStack、CloudStack都是管理系统虚拟化的工具。当然OpenStack、CloudStack还管理这其他的东西，作为比较，暂且忽略。
容器在软件堆栈上，与系统虚拟化KVM和XEN不在一个层面上，即不需要与系统虚拟化竞争，也不需要直接与私有化软件和公有云竞争。事实上，容器离应用和开发者更近，这也是容器快速流行的原因之一。
容器和Docker尽管快速流行，但公有云服务上门迅速消化了这一趋势，各自推出了自己的容器服务： 2014年11月5日GoogleCloud Platform 发布container engine、2014年11月14日亚马逊AWS发布ECS、2015年12月微软Azure发布 ContainerService。但是，所有这些容器服务都是基于它们的IaaS服务之上的。
但是如果真的认为Docker与世无争的话，那就太天真了。虽然Docker现在只是提供镜像相关的服务，而没有基础设施服务，但并不是因为它不想，而是现在云计算基础设施服务的厂家太强大了。但是，看了下面的图，OpenStack、VMware们怕是要出点汗了，要搞的还是私有云厂商啊。
Datadog在2016年1月的一项面向7000个公司的调查显示，docker如今运行在5%的主机上，一年前这个数字几乎为0，这不包括运行CoreOS等其他容器平台的主机。使用docker用到的排名前十的技术包括：Registry、nginx、redis、ubuntu、logspout、mongodb、elasticsearch、CAdvisor、Mysql、Postgres。
正如我在penStack和Docker不能，Kubernetes和Mesos也不能，ServerLess能决定云计算胜负吗？》一文中所说，docker诞生与paas服务dotCloud。但独立的PaaS服务至今未能显示出成功的可能，至于原因，看过《云计算时代》一书和我其他文章的，应该很明了原因。
但这并不妨碍容器和docker，如今成为云计算领域，最受瞩目和最有前景的技术和项目。
Docker能如此成功有两个重要原因：
IaaS的兴起。IaaS将基础设施的可扩展性和灵活性，推向了一个新台阶。但位于基础设施之上的应用，其一致性性和可管理性并没有大的改观。而容器的兴起，正好补位。
DevOps的兴起。DevOps在云计算星期后不久，就开始被提出，并受到部分欢迎。DevOps基于IaaS和私有云，当然也能比传统的开发流程更为高效。但，DevOps的流程和工具，配合容器技术，将让应用的生命周期管理更为流畅。
至于经常与容器并提的MicroServcie微服务，只是容器发展的结果而不是原因，初看是SOA、Mashable落地的另一种表现形式罢了。但微服务将传统的SOA中的服务分解得更细，而且目前的微服务里还没有ESB（EnterpriseService Bus，ESB）和UDDI（Universal Description, Discovery, andIntegration）之类的东西。除此之外，你真的很难从理论和原则上区分SOA和微服务。
但这么多的微服务怎么管理，目前微服务理论还没有告诉我们。
将系统分解为较小的系统，这种做法比起一体性的大规模应用更易于进行错误诊断、变更以及迭代。但是，也只是针对复杂的应用，如果一个基本的简单的应用都要拆分成10个以上微服务，那简直是没事找抽型。
当然，Docker并非没有问题，年轻本身就是问题。Docker还年轻，要想成为一个成熟的IT工具或平台，还有很多问题需要解决。安全、网络、控制，这都是IT管理者对位看重的问题，目前docker刚开始解决这些问题。
但是，docker有过度定位的问题。Docker只是一个OS之上的容器，是否应该承载IaaS层的性能、网络、安全控制，容器从业者和公司们或者都来不及想这个问题，就被需求和野心推着跑过了界限。
另一个过度的，是openstack对docker的恐惧和支持。无论是因为吃醋、恐惧，亦或是拥抱、喜爱，openstack目前在容器上投入了过于多的精力和项目。而且这些项目之间，很难说有多少战略上的兼容和协同考虑。使用OpenStack管理Docker，有3种流行方法：Nova Docker驱动，Heat Docker插件，Ironic、Magnum。
当然，不只是openstack过度支持容器，整个开源社区都是。Docker、OpenShift、Kubernets、Mesos、OpenStack、CloudFoundry、Cloudify都声称自己是容器管理的利器。没错，不管他们以前是什么，现在，他们都是容器管理，特别的，是docker管理的利器。CloudFoundry虽不是基于docker的，但也是基于容器的，但是decker项目把两者联系到了一起。容器是要把PaaS变成CaaS（Caitaineras a Service）啊。
目前，在AngelList上至少有20个基于容器或docker的创业公司。Docker自己也收购了一些创业公司，诸如Tutum、Kitematic、SocketPlane,、Koality、Orchard，以及最新的，Unikernal。
3 Unikernal：是极客玩具还是在5年内干掉容器和docker
Docker因为其轻量级，应用启动更为迅速，资源利用更为高效。循着这个思路，Unikernels更进了一步。再试Unikernels并没有基于传统的软件堆栈之上。
在以前的软件堆栈上，不管采用那种机构，总会有一个通用操作系统存在于其中一层。或者在Xen之上的GuestOS，或者在Container之下的HOSTOS。而Unikernels想改变这个状况，要打通特定应用到硬件之间的所有堆栈，让这个堆栈里面不再有任何特定应用所不需要的冗余。
Unikernals是一个定制的操作系统，专为特定的应用程序的运行而编译。因此，开发者能够创建一个极度精简的OS，只包含应用和它所需的操作系统组件。Unikernals是单用户、单进程、单任务的定制操作系统，它在编译时去除了所有不需要的功能，但包含了一个软件运行所需的全部堆栈：OS内核、系统库、语言运行时环境、应用，这些被编译成一个可启动的VM镜像，直接运行在标准的hypervisor上。
Unikernals实现的例子包括MirageOS、Clive、OSv、Rumprun等，目前都跑在XenHypervisor上。MirageOS 和HaLVM强调纯粹和安全，ClickOS强调性能，OSv和Rumpkernels强调兼容现有的应用。
Unikernals有多小呢？一个MirageOSDNS镜像是200KB，而一个目前全球90%DNS使用的开源DNS服务器BIND镜像是400MB。而MirageOSDNS镜像的性能据称比BIND好45%。
咦？这种尺寸不是嵌入式系统吗？Unikernals当然可以编译出镜像，运转在低功耗的设备上。如果Unikernals被移植到ARM平台上，开发者就可以编译出运行在ARM设备的hypervisor上的镜像。这将让嵌入式应用的开发更为容易。
当然，如同嵌入式程序一样，Unikernals的镜像容易做到精简、高效、稳定。
Unikernals的好处大概这么几点：
l 小尺寸。Unikernals虽然包含操作系统部分，但其尺寸甚至比不包含操作系统核心的容器镜像还要小。大部分镜像可能只有几十MB，这使得在互联网上实时传输镜像成为可能。
l 快速部署和启动。因为精简，不仅传输速度块，启动速度也快。最新的实现，Unikernals镜像启动是在在20毫秒以内。
l 高安全。同样因为精简，攻击面极小。
不过，和docker一样，灵活带来的伴生问题，就是管理、监控、回溯、审计，还有兼容。因为对应用改一行代码要重新编译整个镜像并部署，无法对一个Unikernals实例打补丁，也就是通常说的：Unikernals的实例是静态的。
这就是不可变基础设施与部署。不可变基础设施与部署，是指永远不要改动运行中的基础设施或应用程序，而总是将应用或基础设施销毁后再重新生成。原因是：比起创建新的服务，对已有的服务进行变更并追踪这些变更可能更加困难，它要求你对于某个复杂系统中的一切变量都充分理解并且具有控制权。对于小型应用来说这一点或许问题不大，但大多数现代化的复杂应用程序都是通过功能与补丁的无数次迭代混合而成的。在这种复杂应用中进行手动变更几乎是不可能的。
人和公司，要有分工，VM也要有分工。Unikernals让VM完成了分工，一个VM就干一个事服务于一个应用，这样最高效。
Unikernals的精简带来的小尺寸、快速部署启动、高安全，至少能够补充现有的裸机、系统虚拟化、容器构成的体系，甚至有可能替代容器。
5年之内见分晓。
因为目前，Unikernals还处于实验室阶段，正在验证可行性。构建工具、平台、生态，还未开始，在开发、测试环境还没有得到应用。
Docker想借收购Unikernals为容器保驾护航，甚至想成为IT管理老大。但容器玩家不只是收购Unikernals的docker，从大公司到小企业，都对容器寄予厚望，那么问题来了，兼容性怎么办？兼容性以后再谈，咱们先抱个团吧，搞两位公有云老大亚马逊AWS和微软Azure，于是CloudNative Computing基金会成立了。
4 Cloud Native Computing Foundation：云计算失意者和挑战者借容器搞反垄断联盟
没错，这回又是google牵头。
2015年7月21日，谷歌联合linux基金会及其他合作伙伴共同成立了CNCF基金会( CloudNative ComputingFoundation)，并将kuberentes作为首个编入CNCF管理体系的开源项目。来，我们来看一下发起人：AT&T,Box, Cisco, Cloud FoundryFoundation, CoreOS,, Docker, eBay, Google, Huawei, IBM, Intel,Joyent, Kismatic, Mesosphere, RedHat, Twitter, Univa, VMware等。
在此前后，谷歌加入了OpenStack基金会，openstack上可以部署运行kubernetes，OpenStack支持docker，Mesos支持docker和kubernetes。大家互相都支持，谁能发展好，各自努力吧。这关系够乱的。
但是，容器的另外两个大玩家-亚马逊和微软，没有到场。没错，容器界就是要掀翻现有的云计算格局，当然不能让云计算老大和老二进来了。另外，HPE没来，估计忙着分拆，没敢上容器这趟车。或者大家认为HPE已经一蹶不振了？
谷歌纠集了一帮小兄弟，誓要利用容器浪潮，干翻亚马逊aws和微软azure。大家整合在Cloud Native 的名义下。
Cloud Native到底是个什么东西？什么东西都不是。
Cloud Native是Pivotal的MattStine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付（ContinuousDelivery）、微服务（MicroServices）、敏捷基础设施（AgileInfrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。CloudNative也可以说是一系列Cloud技术、企业管理方法的集合。
Cloud Native只是糅杂，你也可以说封装，现存的一些概念。容器是工具，DevOps和微服务是方法，持续交付是目标。
从概念的本意上说，CloudNative是指部署在传统IT基础设施上的应用架构不适合云化的环境，应该充分利用云基础设施的可编程性和扩展性，又要规避云基础设施的不可靠，核心将基础设施为应用而设计改为应用为云化的基础设施而设计。
你也可以认为CloudNative是一系列在云上构建基础设施的最佳实践。它要求我们进行组织变革、组织变革、推行持续交付、建设敏捷基础设施、采用微服务架构。
Open data centeralliance(ODCA)一篇论文“Best Practices: ArchitectingCloud-Aware Applications Rev.1.0”，描述了一个从0到3的四级成熟度模型。0级是最低要求，应用可以快速和容易的部署到云上的虚拟机。1级是松耦合，比如应用和存储、网络配置松耦合，2级是完全松耦合，比如微服务，3级是自动化伸缩。
论文还描述了12个架构准则：面向失败、面向延迟等。微服务也有12因子（Twelve-Factor）规范，不赘述。
CNCF，就是想搞一个为云而生的参考基础设施架构。初始的两个项目，就是Google的Kubernets和Mesosphere的Mesos。在此之前一个月，Docker已经发起了OpenContainerInitiative，想定义容器运行时和格式标准。OCI关注容器本身，而CNCF关注如何管理和用好容器。
但是注意，参加OCI的三个成员：Amazon Web Services,EMC andMicrosoft。并没有参加到CNCF。当然和发起者Gogole脱不了干系。CNCF的核心就是谷歌发布的Kubernets，Kubernets也是谷歌容器服务ContainerEngine的核心。而亚马逊AWS和微软已经有了自己的容器服务。这又是一个开源、联盟对抗商业老大的故事。想到OpenStack了吧？
团结就是力量。但谷歌也没有笨到准备靠容器或联盟就一招制胜，云大战还有另一个重要战场：Serverless。
5 ServerLess：决定云计算胜负的战场?
2014年11月14日，亚马逊AWS发布了新产品Lambda。2015年2月9日，google发布CloudFunctions。这两款都是ServerLess产品。包括google2014年10月22日收购的实时后端数据库创业公司Firebase，Facebook在2014年二月收购而在2016年2月将关闭的 Parse，都属于ServerLess。
ServerLess，顾名思义，没有服务器。但是，不是说它不需要服务器，那是不可能的。而是用户不需要关心服务器。从这一点上看，你应该已经想到了PaaS，这就是一个简单的PaaS服务。
用户不需要关心基础设施，只需要关心业务，这是迟到的PaaS，也是更实用的PaaS。这很有可能将会变革整个开发过程和传统的应用生命周期，一旦开发者们习惯了这种全自动的云上资源的创建和分配，或许就再也回不到那些需要微应用配置资源的时代里去了。自此，将进入“NoOps“时代。
2016年，微软很可能发布Azure的Serverless产品。
Serverless也许很重要，可能是将来的重要战场，甚至决定性战场。但当下，更重要的是数据分析战场。
6 数据分析和开放数据燃起熊熊战火：IBM以此作为主战场
大数据不知道是不是创业公司的菜，但目前来看很可能是巨头们的菜。
大数据本是个伪命题。数据其实就是现代信息的载体，可以说数据就是信息。而大和小并没有严格的界限，小数据同大数据一样的重要，只是大说起来更好听更高大上罢了。
IBM猛炒Watson，Google大推AlphaGo围棋，都意在为各自的数据分析服务正面或侧面背书。但微软Azure和亚马逊AWS，不可能在大数据红火时袖手旁观。
Google拥有面向分析的数据仓库BigQuery、批式和流式数据处理DataFlow、Hadoop和Spark服务DataPro、数据分析与展示的交互工具DataLab、实时消息服务PubSub五款产品。
微软目前拥有适用数据分析的大规模存储库Data Lake、分布式分析Data Lake分析、托管HD集群HDInsight、基于云的预测分析Machine learning、实时流式分析StreamAnalysis等近10个数据存储和分析服务。
AmazonAWS目前拥有Hadoop框架EMR、周期性数据驱动工作流编排服务Data PipeLine、搜索服务ElasticSearch、实时流式数据处理Kinesis、机器学习Amazon MachineLearning、商业智能服务Amazon QuickInsight、数据仓库Redshift七款产品。
这些产品，特别是Google和微软，都是近两年发布的。而IBM的大部分分析产品甚至是2015年发布的，而IBM而力陈Watson是其云计算之战的秘密武器。IBM2014年9月发布沃森分析（WatsonAnalytics），支持用户上传数据并通过英语语句查询分析结果，还能根据不同的分析场景向用户建议数据清洗步骤，以及最佳的数据可视化方法，支持自然语言查询。
亚马逊AWS和IBM也发布了不少开放数据。
亚马逊AWS上的开放数据包括对 Landsat 8 卫星拍摄的中等分辨率地球陆地卫星图像、下一代气象雷达 (NEXRAD)网络的实时和存档数据、NASA 维护的气候变化预测和地球表面的卫星图像、包含超过 50 亿网页的 Web爬取数据语料库、人类遗传变异详图等数十种开放数据。
谷歌2013年推出的一项云端服务GoogleGenomics，帮助大学实验室和医院等机构将患者或科研对象的生物基因储存到云端上，推进人类基因组信息的存储、对比和分析。
2015年2月底，谷歌加入了全球基因组学与健康联盟(Global Alliance for Genomics andHealth)，旨在推进基因组和临床数据的安全和有效共享。
Google Genomics和基因数据创业公司Tute Genomics2015年3月宣布，TuteGenomics将把其海量基因信息数据库放到Google Genomics平台上以便于查询。GoogleGenomics托管的其他基因数据库还包括1000 Genomes Project、Illumina PlatinumGenomes和MSSNG Database for Autism Researchers等。
2016年2月5日，IBM一口气发布了4款数据分析产品：IBM Compose Enterprise, IBM Graph, IBMPredictive Analytics 和 IBMAnalytics Exchange。
但是，如果后来者和挑战者，没有强劲的IaaS服务规模，而意图用大数据、移动、物联网趋势进行弯道超车，究竟是后发优势呢？还是战略陷阱呢？
无论采用什么战略和战术，最后不还是营收和利润说了算。但营收这个事，在云计算行业，特别是IaaS和PaaS行业，真是云里雾里。
7 云服务的营收都是云里雾里，除了亚马逊AWS
一方面，这是因为IaaS和PaaS目前还没有独立的上市公司，所以难以判断营收增长和利润数据，另一方面，从事IaaS和PaaS的大公司们，在这个业务上的收入相对总体收入，比例小，不想或没有必要披露。
2015年之前，所有人都在问云计算能够带来多大的业务？能不能有利可图？
但亚马逊AWS打破了这个格局。
一如既往，本文关注的不是云计算全产业链，本文关注限于IaaS和PaaS话题，PaaS也只是顺便提及，SaaS等领域跑题时才会提及。
一如既往，由于所有信息不是来源于严谨的调查和统计，也许离事实差距甚远，但仍希望读者能藉此文窥得中国和全球IPaaS之现状。如果能对中国IPaaS行业有所助益，或对相关同仁有所启发，甚或只是打发了时间，也不枉本文诞生过程中的敲敲打打。喜欢快餐的，可以直接翻过本文；对于习惯严谨数字的读者，请提前知悉本文的粗放和调侃。
一如既往，本文不从头解释基本概念和行业内的基本知识。如果你希望系统性学习云计算各个领域的基本知识，购买《云计算时代:本质、技术、创新、战略》差不多是最佳选择了。不想花钱没关系，这个公众号鸣北林的上一篇文章就是<中国IaaS产业2012年度点评>，里面没有基础知识但有历史知识。如果你真的需要了解更多，还是狠狠心买一本《云计算时代:本质、技术、创新、战略》。
不一如既往的是，本文不在区分去年总结和来年预测。年份，本就是认为划定的线线，但时间和云计算，不会按照线线来跳跃式前进，那就让总结和预测你中有我我中有你吧。
今天触发了2万字微信文章上限，删略了一些文字。
1 Openstack看起来不可阻挡，但还未等来属于自己的时代
中国想以OpenStack为生的公司么有100家，也有50家。国外的公司也不会比这少。这是OpenStack的福音，却不是OpenStack公司和用户的福音，太多的同质竞争者，太多的私有版本，而且这些竞争者和私有版本有95%将在三年内消失。这些拿OpenStack搞公有云的，根本就不清楚一点：即使OpenStack没有上述那些问题，即使OpenStack是一个开源的VMWare或开源的AWS，要做公有云，还是要自己开发。为什么？不是不告诉你，是在懒得再说，如果想不明白这个问题，就别搞IaaS了。
搞公有云搞不过AWS，大家拿OpenStack开始搞私有云。私有云那是VMWare和微软的地盘，但是现在VMWare和私有云都已经过了辉煌期，搞起来说不定容易点也未可知。
但OpenStack能否迎来自己的时代，取决于它在混合云上的作为。纯私有云不大可能是将来的主流模式，这个领域也有VMware和微软坚守。公有云市场基本没有OpenStack的空间。混合云才是OpenStack的战场。但现有的私有云项目和厂商肯定会极力抓住混合云的机会，甚至随着时间推移混合云可能走向边缘。
2016，我们将看到OpenStack是否能在搞VMware的战役中取得第一站的胜利：OpenStack能否在企业的生产环境中得到大量的部署。
2016，我们或许还看不到OpenStack迈开走向混合云的第一步。这也许需要更长的时间，毕竟搞私有云的战役才刚打响。
但OpenStack的影响力，注定要被docker超越。
2 容器和Docker：准备好迎接它的黄金时代
Docker本就和OpenStack不是一个层面，本就不应该发生争吵。但还是发生了，为什么？吃醋。Docker应用的基础技术和工具虽然是老古董，但它一出生就得到了开发者特别是DevOps、Microservice拥护者的青睐，并迅速俘获大批开发者和媒体、观察者的芳心。
Docker太流行了，太引人注目了。OpenStack支持者吃醋了。2014年8月，Linux.com和网站NewStack联合开展，从550多个调查对象那里收集了信息。关于谁是总体上最佳的开源云计算项目的问题：OpenStack、Docker、KVM、CloudStack、Ceph排名前五。但在此之后不久，通过Google的搜索量显示，Docker的热度全面超过OpenStack。
于是，有了所谓的论战。有人发出战帖：用Docker之后还需要OpenStack吗?当然可以不要。比如：叫板OpenStack:八步用Docker实现私有云。Docker当然非常适合私有云。
甚至在OpenStack峰会上最热门的主题是：Docker以及容器技术是否会替代OpenStack？这压根就是伪命题，太多假设和想当然了。无论将docker看成容器技术还是管理平台，它都与KVM和XEN这些系统虚拟化和OpenStack，不是直接替代关系。当然，间接替代是可以的，但不是必然的。
但是，这些都是Docker发展道路上的插曲。
容器是操作系统虚拟化技术，xen和kvm是系统虚拟化技术，他们在技术堆栈上处于不同的层级。Docker、Kubernets都是管理容器的工具，OpenStack、CloudStack都是管理系统虚拟化的工具。当然OpenStack、CloudStack还管理这其他的东西，作为比较，暂且忽略。
容器在软件堆栈上，与系统虚拟化KVM和XEN不在一个层面上，即不需要与系统虚拟化竞争，也不需要直接与私有化软件和公有云竞争。事实上，容器离应用和开发者更近，这也是容器快速流行的原因之一。
容器和Docker尽管快速流行，但公有云服务上门迅速消化了这一趋势，各自推出了自己的容器服务： 2014年11月5日GoogleCloud Platform 发布container engine、2014年11月14日亚马逊AWS发布ECS、2015年12月微软Azure发布 ContainerService。但是，所有这些容器服务都是基于它们的IaaS服务之上的。
但是如果真的认为Docker与世无争的话，那就太天真了。虽然Docker现在只是提供镜像相关的服务，而没有基础设施服务，但并不是因为它不想，而是现在云计算基础设施服务的厂家太强大了。但是，看了下面的图，OpenStack、VMware们怕是要出点汗了，要搞的还是私有云厂商啊。
Datadog在2016年1月的一项面向7000个公司的调查显示，docker如今运行在5%的主机上，一年前这个数字几乎为0，这不包括运行CoreOS等其他容器平台的主机。使用docker用到的排名前十的技术包括：Registry、nginx、redis、ubuntu、logspout、mongodb、elasticsearch、CAdvisor、Mysql、Postgres。
正如我在penStack和Docker不能，Kubernetes和Mesos也不能，ServerLess能决定云计算胜负吗？》一文中所说，docker诞生与paas服务dotCloud。但独立的PaaS服务至今未能显示出成功的可能，至于原因，看过《云计算时代》一书和我其他文章的，应该很明了原因。
但这并不妨碍容器和docker，如今成为云计算领域，最受瞩目和最有前景的技术和项目。
Docker能如此成功有两个重要原因：
IaaS的兴起。IaaS将基础设施的可扩展性和灵活性，推向了一个新台阶。但位于基础设施之上的应用，其一致性性和可管理性并没有大的改观。而容器的兴起，正好补位。
DevOps的兴起。DevOps在云计算星期后不久，就开始被提出，并受到部分欢迎。DevOps基于IaaS和私有云，当然也能比传统的开发流程更为高效。但，DevOps的流程和工具，配合容器技术，将让应用的生命周期管理更为流畅。
至于经常与容器并提的MicroServcie微服务，只是容器发展的结果而不是原因，初看是SOA、Mashable落地的另一种表现形式罢了。但微服务将传统的SOA中的服务分解得更细，而且目前的微服务里还没有ESB（EnterpriseService Bus，ESB）和UDDI（Universal Description, Discovery, andIntegration）之类的东西。除此之外，你真的很难从理论和原则上区分SOA和微服务。
但这么多的微服务怎么管理，目前微服务理论还没有告诉我们。
将系统分解为较小的系统，这种做法比起一体性的大规模应用更易于进行错误诊断、变更以及迭代。但是，也只是针对复杂的应用，如果一个基本的简单的应用都要拆分成10个以上微服务，那简直是没事找抽型。
当然，Docker并非没有问题，年轻本身就是问题。Docker还年轻，要想成为一个成熟的IT工具或平台，还有很多问题需要解决。安全、网络、控制，这都是IT管理者对位看重的问题，目前docker刚开始解决这些问题。
但是，docker有过度定位的问题。Docker只是一个OS之上的容器，是否应该承载IaaS层的性能、网络、安全控制，容器从业者和公司们或者都来不及想这个问题，就被需求和野心推着跑过了界限。
另一个过度的，是openstack对docker的恐惧和支持。无论是因为吃醋、恐惧，亦或是拥抱、喜爱，openstack目前在容器上投入了过于多的精力和项目。而且这些项目之间，很难说有多少战略上的兼容和协同考虑。使用OpenStack管理Docker，有3种流行方法：Nova Docker驱动，Heat Docker插件，Ironic、Magnum。
当然，不只是openstack过度支持容器，整个开源社区都是。Docker、OpenShift、Kubernets、Mesos、OpenStack、CloudFoundry、Cloudify都声称自己是容器管理的利器。没错，不管他们以前是什么，现在，他们都是容器管理，特别的，是docker管理的利器。CloudFoundry虽不是基于docker的，但也是基于容器的，但是decker项目把两者联系到了一起。容器是要把PaaS变成CaaS（Caitaineras a Service）啊。
目前，在AngelList上至少有20个基于容器或docker的创业公司。Docker自己也收购了一些创业公司，诸如Tutum、Kitematic、SocketPlane,、Koality、Orchard，以及最新的，Unikernal。
3 Unikernal：是极客玩具还是在5年内干掉容器和docker
Docker因为其轻量级，应用启动更为迅速，资源利用更为高效。循着这个思路，Unikernels更进了一步。再试Unikernels并没有基于传统的软件堆栈之上。
在以前的软件堆栈上，不管采用那种机构，总会有一个通用操作系统存在于其中一层。或者在Xen之上的GuestOS，或者在Container之下的HOSTOS。而Unikernels想改变这个状况，要打通特定应用到硬件之间的所有堆栈，让这个堆栈里面不再有任何特定应用所不需要的冗余。
Unikernals是一个定制的操作系统，专为特定的应用程序的运行而编译。因此，开发者能够创建一个极度精简的OS，只包含应用和它所需的操作系统组件。Unikernals是单用户、单进程、单任务的定制操作系统，它在编译时去除了所有不需要的功能，但包含了一个软件运行所需的全部堆栈：OS内核、系统库、语言运行时环境、应用，这些被编译成一个可启动的VM镜像，直接运行在标准的hypervisor上。
Unikernals实现的例子包括MirageOS、Clive、OSv、Rumprun等，目前都跑在XenHypervisor上。MirageOS 和HaLVM强调纯粹和安全，ClickOS强调性能，OSv和Rumpkernels强调兼容现有的应用。
Unikernals有多小呢？一个MirageOSDNS镜像是200KB，而一个目前全球90%DNS使用的开源DNS服务器BIND镜像是400MB。而MirageOSDNS镜像的性能据称比BIND好45%。
咦？这种尺寸不是嵌入式系统吗？Unikernals当然可以编译出镜像，运转在低功耗的设备上。如果Unikernals被移植到ARM平台上，开发者就可以编译出运行在ARM设备的hypervisor上的镜像。这将让嵌入式应用的开发更为容易。
当然，如同嵌入式程序一样，Unikernals的镜像容易做到精简、高效、稳定。
Unikernals的好处大概这么几点：
l 小尺寸。Unikernals虽然包含操作系统部分，但其尺寸甚至比不包含操作系统核心的容器镜像还要小。大部分镜像可能只有几十MB，这使得在互联网上实时传输镜像成为可能。
l 快速部署和启动。因为精简，不仅传输速度块，启动速度也快。最新的实现，Unikernals镜像启动是在在20毫秒以内。
l 高安全。同样因为精简，攻击面极小。
不过，和docker一样，灵活带来的伴生问题，就是管理、监控、回溯、审计，还有兼容。因为对应用改一行代码要重新编译整个镜像并部署，无法对一个Unikernals实例打补丁，也就是通常说的：Unikernals的实例是静态的。
这就是不可变基础设施与部署。不可变基础设施与部署，是指永远不要改动运行中的基础设施或应用程序，而总是将应用或基础设施销毁后再重新生成。原因是：比起创建新的服务，对已有的服务进行变更并追踪这些变更可能更加困难，它要求你对于某个复杂系统中的一切变量都充分理解并且具有控制权。对于小型应用来说这一点或许问题不大，但大多数现代化的复杂应用程序都是通过功能与补丁的无数次迭代混合而成的。在这种复杂应用中进行手动变更几乎是不可能的。
人和公司，要有分工，VM也要有分工。Unikernals让VM完成了分工，一个VM就干一个事服务于一个应用，这样最高效。
Unikernals的精简带来的小尺寸、快速部署启动、高安全，至少能够补充现有的裸机、系统虚拟化、容器构成的体系，甚至有可能替代容器。
5年之内见分晓。
因为目前，Unikernals还处于实验室阶段，正在验证可行性。构建工具、平台、生态，还未开始，在开发、测试环境还没有得到应用。
Docker想借收购Unikernals为容器保驾护航，甚至想成为IT管理老大。但容器玩家不只是收购Unikernals的docker，从大公司到小企业，都对容器寄予厚望，那么问题来了，兼容性怎么办？兼容性以后再谈，咱们先抱个团吧，搞两位公有云老大亚马逊AWS和微软Azure，于是CloudNative Computing基金会成立了。
4 Cloud Native Computing Foundation：云计算失意者和挑战者借容器搞反垄断联盟
没错，这回又是google牵头。
2015年7月21日，谷歌联合linux基金会及其他合作伙伴共同成立了CNCF基金会( CloudNative ComputingFoundation)，并将kuberentes作为首个编入CNCF管理体系的开源项目。来，我们来看一下发起人：AT&T,Box, Cisco, Cloud FoundryFoundation, CoreOS,, Docker, eBay, Google, Huawei, IBM, Intel,Joyent, Kismatic, Mesosphere, RedHat, Twitter, Univa, VMware等。
在此前后，谷歌加入了OpenStack基金会，openstack上可以部署运行kubernetes，OpenStack支持docker，Mesos支持docker和kubernetes。大家互相都支持，谁能发展好，各自努力吧。这关系够乱的。
但是，容器的另外两个大玩家-亚马逊和微软，没有到场。没错，容器界就是要掀翻现有的云计算格局，当然不能让云计算老大和老二进来了。另外，HPE没来，估计忙着分拆，没敢上容器这趟车。或者大家认为HPE已经一蹶不振了？
谷歌纠集了一帮小兄弟，誓要利用容器浪潮，干翻亚马逊aws和微软azure。大家整合在Cloud Native 的名义下。
Cloud Native到底是个什么东西？什么东西都不是。
Cloud Native是Pivotal的MattStine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付（ContinuousDelivery）、微服务（MicroServices）、敏捷基础设施（AgileInfrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。CloudNative也可以说是一系列Cloud技术、企业管理方法的集合。
Cloud Native只是糅杂，你也可以说封装，现存的一些概念。容器是工具，DevOps和微服务是方法，持续交付是目标。
从概念的本意上说，CloudNative是指部署在传统IT基础设施上的应用架构不适合云化的环境，应该充分利用云基础设施的可编程性和扩展性，又要规避云基础设施的不可靠，核心将基础设施为应用而设计改为应用为云化的基础设施而设计。
你也可以认为CloudNative是一系列在云上构建基础设施的最佳实践。它要求我们进行组织变革、组织变革、推行持续交付、建设敏捷基础设施、采用微服务架构。
Open data centeralliance(ODCA)一篇论文“Best Practices: ArchitectingCloud-Aware Applications Rev.1.0”，描述了一个从0到3的四级成熟度模型。0级是最低要求，应用可以快速和容易的部署到云上的虚拟机。1级是松耦合，比如应用和存储、网络配置松耦合，2级是完全松耦合，比如微服务，3级是自动化伸缩。
论文还描述了12个架构准则：面向失败、面向延迟等。微服务也有12因子（Twelve-Factor）规范，不赘述。
CNCF，就是想搞一个为云而生的参考基础设施架构。初始的两个项目，就是Google的Kubernets和Mesosphere的Mesos。在此之前一个月，Docker已经发起了OpenContainerInitiative，想定义容器运行时和格式标准。OCI关注容器本身，而CNCF关注如何管理和用好容器。
但是注意，参加OCI的三个成员：Amazon Web Services,EMC andMicrosoft。并没有参加到CNCF。当然和发起者Gogole脱不了干系。CNCF的核心就是谷歌发布的Kubernets，Kubernets也是谷歌容器服务ContainerEngine的核心。而亚马逊AWS和微软已经有了自己的容器服务。这又是一个开源、联盟对抗商业老大的故事。想到OpenStack了吧？
团结就是力量。但谷歌也没有笨到准备靠容器或联盟就一招制胜，云大战还有另一个重要战场：Serverless。
5 ServerLess：决定云计算胜负的战场?
2014年11月14日，亚马逊AWS发布了新产品Lambda。2015年2月9日，google发布CloudFunctions。这两款都是ServerLess产品。包括google2014年10月22日收购的实时后端数据库创业公司Firebase，Facebook在2014年二月收购而在2016年2月将关闭的 Parse，都属于ServerLess。
ServerLess，顾名思义，没有服务器。但是，不是说它不需要服务器，那是不可能的。而是用户不需要关心服务器。从这一点上看，你应该已经想到了PaaS，这就是一个简单的PaaS服务。
用户不需要关心基础设施，只需要关心业务，这是迟到的PaaS，也是更实用的PaaS。这很有可能将会变革整个开发过程和传统的应用生命周期，一旦开发者们习惯了这种全自动的云上资源的创建和分配，或许就再也回不到那些需要微应用配置资源的时代里去了。自此，将进入“NoOps“时代。
2016年，微软很可能发布Azure的Serverless产品。
Serverless也许很重要，可能是将来的重要战场，甚至决定性战场。但当下，更重要的是数据分析战场。
6 数据分析和开放数据燃起熊熊战火：IBM以此作为主战场
大数据不知道是不是创业公司的菜，但目前来看很可能是巨头们的菜。
大数据本是个伪命题。数据其实就是现代信息的载体，可以说数据就是信息。而大和小并没有严格的界限，小数据同大数据一样的重要，只是大说起来更好听更高大上罢了。
IBM猛炒Watson，Google大推AlphaGo围棋，都意在为各自的数据分析服务正面或侧面背书。但微软Azure和亚马逊AWS，不可能在大数据红火时袖手旁观。
Google拥有面向分析的数据仓库BigQuery、批式和流式数据处理DataFlow、Hadoop和Spark服务DataPro、数据分析与展示的交互工具DataLab、实时消息服务PubSub五款产品。
微软目前拥有适用数据分析的大规模存储库Data Lake、分布式分析Data Lake分析、托管HD集群HDInsight、基于云的预测分析Machine learning、实时流式分析StreamAnalysis等近10个数据存储和分析服务。
AmazonAWS目前拥有Hadoop框架EMR、周期性数据驱动工作流编排服务Data PipeLine、搜索服务ElasticSearch、实时流式数据处理Kinesis、机器学习Amazon MachineLearning、商业智能服务Amazon QuickInsight、数据仓库Redshift七款产品。
这些产品，特别是Google和微软，都是近两年发布的。而IBM的大部分分析产品甚至是2015年发布的，而IBM而力陈Watson是其云计算之战的秘密武器。IBM2014年9月发布沃森分析（WatsonAnalytics），支持用户上传数据并通过英语语句查询分析结果，还能根据不同的分析场景向用户建议数据清洗步骤，以及最佳的数据可视化方法，支持自然语言查询。
亚马逊AWS和IBM也发布了不少开放数据。
亚马逊AWS上的开放数据包括对 Landsat 8 卫星拍摄的中等分辨率地球陆地卫星图像、下一代气象雷达 (NEXRAD)网络的实时和存档数据、NASA 维护的气候变化预测和地球表面的卫星图像、包含超过 50 亿网页的 Web爬取数据语料库、人类遗传变异详图等数十种开放数据。
谷歌2013年推出的一项云端服务GoogleGenomics，帮助大学实验室和医院等机构将患者或科研对象的生物基因储存到云端上，推进人类基因组信息的存储、对比和分析。
2015年2月底，谷歌加入了全球基因组学与健康联盟(Global Alliance for Genomics andHealth)，旨在推进基因组和临床数据的安全和有效共享。
Google Genomics和基因数据创业公司Tute Genomics2015年3月宣布，TuteGenomics将把其海量基因信息数据库放到Google Genomics平台上以便于查询。GoogleGenomics托管的其他基因数据库还包括1000 Genomes Project、Illumina PlatinumGenomes和MSSNG Database for Autism Researchers等。
2016年2月5日，IBM一口气发布了4款数据分析产品：IBM Compose Enterprise, IBM Graph, IBMPredictive Analytics 和 IBMAnalytics Exchange。
但是，如果后来者和挑战者，没有强劲的IaaS服务规模，而意图用大数据、移动、物联网趋势进行弯道超车，究竟是后发优势呢？还是战略陷阱呢？
无论采用什么战略和战术，最后不还是营收和利润说了算。但营收这个事，在云计算行业，特别是IaaS和PaaS行业，真是云里雾里。
7 云服务的营收都是云里雾里，除了亚马逊AWS
一方面，这是因为IaaS和PaaS目前还没有独立的上市公司，所以难以判断营收增长和利润数据，另一方面，从事IaaS和PaaS的大公司们，在这个业务上的收入相对总体收入，比例小，不想或没有必要披露。
2015年之前，所有人都在问云计算能够带来多大的业务？能不能有利可图？
但亚马逊AWS打破了这个格局。