还记得在十多年前，SaaS鼻祖SalesForce喊出的口号“No Software”吗？SalesForce在这个口号声中开创了SaaS行业，并成为当今市值460亿美元的SaaS之王。今天谈谈“No Server“有关的事。
为啥标题这么多词，这么长呢？一个个写，我得多少篇才能说明白这个事？都攒了这么多了，一次说了完了。继续攒下去，太多了，可能就没法说了。
开始于Eucalyptus， 终结于OpenStack，不仅是从众，而且想取巧并弯道超车
在2008、2009、2010那三年，虽然过来还处于云计算的蛮荒年代，但国外敏锐的开发者和公司已经看到云计算的星星之火。像国人一样，他们也想在这火成燎原之势前，以最小的风险、最小的投入、最快的时间，分得最大一杯羹。
当然，最先行、最敏锐的是开发者们。
彼时，从虚拟化管理到公有云API，热闹异常。
虚拟化管理曾领过风骚的就有virtualiron、3tera、qlayer、OpenNebula、abiquo、virtmanager、ovirt、xenserver、convirt、ganeti、proxmox、Enomalism。
相信我，2009年4月的时候，最牛的就是这几个：Enomalism、ConVirt、ovirt、Virtual Manager。那会连Eucalyptus都感觉很难用。
当然，最后归结于Eucalyptus 、CloudStack和OpenStack。
关于他们的优劣和成败原因的分析，已有很多。三者中，Eucalyptus出身最学术，CloudStack出身商业味最浓，OpenStack介于两者之间。或许，这是OpenStack成功的重要因素？我认为采用Python语言也是重要因素之一。
Eucalyptus出现最早，2008年就出来了，是由加州大学圣塔芭芭拉分校的Rich Wolski和他的博士弟子们开始的。NASA最开始也是使用的Eucalyptus啊。但是，学术机构，还是从事HPC的嘛，虽然一开始就对标和兼容EC2 API，但可用性还是差了那么些，特别是对商业运作敏感性查了一些。
及至后来，引进了Mysql的创始人Martin，加快了商业化步伐，怎奈OpenStack势头已成，且OpenStack没有商业公司控制，这一点很重要，大咖们都喜欢玩不受商业公司控制的，由基金会管理的项目。
OpenStack出现的晚多了，2010年才出现。NASA最开始也是使用Eucalyptus，据说NASA想给Eucalyptus开源版本贡献patch，但Eucalyptus没接受，Eucalyptus不会玩社区嘛。NASA的六个开发人员，用了一个星期时间用Python 做出来一套原型，结果，能跑。这就是Nova的起源。NASACIO跟 Raskspace一个副总走得近，于是NASA 贡献 Nova ， Raskspace贡献swift，在2010年的7月发起了 OpenStack 项目。
CloudStack也在2008年成立。CloudStack一开始就用了cloud.com这个域名，让我觉得背后的团队太有商业眼光了。这个域名肯定花了不少钱，但将来一定能挣回来。因为那会用全部力量扑在虚拟化上的团队，不多。
那会，OpenStack刚成立的时候，CloudStack还是OpenStack的成员呢。为嘛？我也没想通。
但是，CloudStack和Eucalyptus一样，最开始并不开源，开源后还留了点尾巴，而且自己控制着商业版本。等发现这种模式玩不转了，2011年7月卖给了Citrix，全部开源后，发现大家已经都在玩OpenStack了。
OpenStack太好了？为什么？有人已经贡献了很多代码了，其实OpenStack发布后知道CloudStack被Citrix再转卖出去位置，OpenStack的易用性和稳定性一直和CloudStack有差距。但是架不住OpenStack免费、完全开源、没有商业公司控制。
这多好，天上掉下的馅饼。拿来就能用，改改界面就是自己的版本啦。就有软件和产品了，有解决方案了，甚至可以做公有云和亚马逊AWS一决雌雄了。
嘿，这事RackSpace最有发言权。虽然Rackspace2015年才明显放弃公有云的全面竞争，但在2010年，RackSpace决定发起和开源OpenStack项目是，不说明确，至少已经隐隐觉得肯定搞不过亚马逊AWS了。那时，他们与亚马逊AWS的竞争已有三年。
OpenStack本来想另起炉灶，搞一套和AWS EC2不同的API，利用代码和API的开放性，纠结开发者和业内公司，形成一个生态系统，对抗AWS。但是后来，从API到架构，越来越像AWS。
RackSpace当然是这么想的，但是后来的发展却不受自己控制了。来的小公司当然很多，大腕也是不少。当然，RackSpace的投入也是不少。股票得靠云计算支撑啊。公有云发展慢了，OpenStack也是个招牌。
RackSpace的云主机不是收购的slicehost嘛，后来有没有用OpenStack不知道，但云存储基本用的是Swift，基于哪个版本就不好说了。
我猜的是，OpenStack对RackSpace的公有云没有明显帮助。因为OpenStack这样的软件能在一个公有云的运营里面占据的角色太基础了，而且OpenStack需要考虑众多厂家和参与者的需求。
接着上面说，天上掉下的馅饼，谁遇到这好事不嫌弃。其实，OpenStack就功能和稳定性来说，那几个大厂家复制一个是没有问题的。但是，声势不够，没有名声。IT圈也是个圈啊，没有名头也没人关注啊。纯商业版的，VMware和微软已经够了，再搞一个没人要的，还不如在当红炸子鸡OpenStack上投入和榨点油水。当然，也有不少，把大把银子和大堆的人力投入在OpenStack上的。
不投不行啊，自己搞一个没人关注。还不如找个有名头的继续包装。大公司无奈如此。小公司反而更好办了，反正一无所有，拿个现成的起步，有是在东西，还有响亮的名头，必须上啊。
国外不知道，中国想以OpenStack为生的公司么有100家，也有50家。
当然，后来的结果大家都知道了。OpenStack搞AWS没戏，投入最大的HP Helion都要关闭了，其他拿OpenStack搞公有云的就更不用说了。
从RackSpace开始，大家拿OpenStack开始搞私有云。私有云？从开头说的那些开源的，到VMware vshpere、微软system center，那都是相当成熟的。恩，就是贵了点。
现在，OpenStack开始往下走了，私有云了嘛。以前是管理和集成，现在深入到更底层的了，从虚拟机的大页内存、CPU绑定、IO调度，到网络的SDN、NFV，这都得有啊。私有云软件，这个都是可以控制的。
OpenStack现在回过神来搞私有云，那这些都得搞。
但是，有多少人和公司想过，自己需要的是一个新玩意还是一个虚拟化管理工具？是OpenStack的复杂性可扩展性还是顺手和可靠？当然，没有多少人在用之前，对虚拟化管理软件领域有充分的了解，也不一定有资源做充分的调研，流行的就是好的。
后面的事，大家都知道了。正如我在《独孤求败，未必就是王者：OpenStack举杯独酌》一文中所言，CloudStack2015年底被Citrix转卖给Accelerite，而Eucalyptus早在2014年9月就已经委身于HP。
竞争对手一个个倒下，看似势头无敌的时候，也就是最危险的时候。这不，还没等干掉对手的时候，Docker就来了。Docker的渊源虽然很古老，但本身诞生于2013年，是openstack红得发紫，各公司蜂拥而上的那年。
谁也想不到，Docker这个老古董能掀起这么大的波澜，差点让OpenStack翻船。OpenStack最牛的是势，而Docker也是来势汹汹。看看下面的图，IT圈曝光率也是基础啊，面对docker，openstack不心慌才怪。
但其实docker半个老古董。
Docker这半个老古董，掀起了第二波从众，而且想取巧并弯道超车的浪潮
没错，第二波终于来了。
因为不但搞OpenStack没能搞掂公有云，不搞OpenStack的也没能搞掂公有云。得有点新东西出来。
我们先从看看Docker有多老开始。现在看到的docker的起源都不能算起源，只能说出生。其实docker也有老祖先七大姑八大姨的。
任何东西都能追溯到老祖先，虚拟化还能追溯到70年代的大型机呢。那个是有点牵强了，但是docker的直系亲属那也是够老的。
远房的亲戚就不说了，新生代的KVM都6、7年的历史了，老一代的Xen和qemu从2003年算起都十二三年的历史了。在IT行业，10年已经很久了。
但docker的近亲，历史也不短，甚至有的更久。docker它爸lxc从2006年开始开发，到2008年发布0.1.0版本，docker直接间接chroot、cgroup、namespaces、libcontainer使用的其他组件的历史当然也不会比LXC短。它叔叔linux-vserver2003年就已经发布了1.0版本，这是基于内核态隔离的容器。
它还有众多表兄弟Cloudfoundry Warden、BSD jails、Aix workload partitions、iCorevirtual accounts、Sandboxie、Virtuozzo等等，其中Virtuozzo、openvz和solaris container历史都在十年以上。
关注虚拟化和IDC的，有些docker的亲戚应该是很熟悉的。这回又提到IDC了，云计算真实上辈子就跟IDC纠缠在一起。收费的Virtuozzo、免费的openvz，那是云计算和云主机出现之前，Xen和KVM出现之前，搞VPS的利器。10年前VPS卖的多火，被视为虚拟主机的升级版。
Openvz是Virtuozzo容器技术的linux版，LXC是Openvz为了融入内核开发的对应版，开发者大部分是同一批人。LXC及周边工具就是现在Docker的重要组成部分。
Docker出现也就5,6年，但它的大部分身体都出现差不多10年了，你说它是不是半个老古董呢？
Docker本身大家都很熟很熟了，不用赘言。不过经常有人拿Docker和xen、kvm支持的虚拟机对比，说占用体积小、启动速度快，不是一个层级的东西好嘛，一个在操作系统之上，一个在操作系统之下，不赘言了。Docker当然也不能和LXC等linux容器对比，都是用的同一系列核心工具，只是管理层不同而已。
Docker在2013年底，2014年初，突然吸引了众人的目光，并在2014年2015年集万千宠爱于一身，就如前两年的openstack一样。
回到docker诞生的年代，2010年，几个年轻人在旧金山成立了一家做 PaaS 平台的公司-dotcloud。大家现在都知道heroku，也是PaaS型，而且，也用到了容器，可能是LXC吧。当然不是新堆栈PaaS，而是传统堆栈PaaS。这和heroku一样，为开发人员提供操作系统、通用库、特定语言的运行环境，应用的部署、管理、监控等。
dotCloud 把需要花费大量时间的重复性工作，抽象成组件和服务，如规范容器的格式、便利容器的生命周期管理等，方便开发者管理和监控自己的应用。
正如我在《云计算时代》一书中所言，新堆栈PaaS离开发者现有技能太远，传统堆栈PaaS离现有堆栈太近。不管哪种，都挡住了开发者掌控一切的意愿。所以，PaaS多年来虽然独立作为一类云服务，并没有足够大的市场。
虽然dotCloud 在2011年初拿到了1000万美元的融资，但这个市场本没有那么大，也没有快速的增长，容纳不下太多的企业。也没有干过heroku、engineyard等公司，自然前景不妙。
dotCloud 的创始人 Solomon Hykes 把大伙召集到一起，大家琢磨了一下，商业是没戏了，那也要搞一把非商业的事情，把我们在容器上的工作起名docker开源出来。能不能把竞争对手干掉不好说，希望是挺渺茫，但是起码能在社区留个名！万一，开放开源能够搞成更大的势头，公司还能起来呢。
是不是和RackSpace当初搞OpenStack有几分相像？狗急了还要跳墙呢，绝处逢生不是不可能。所谓坚持，耐心，就是这个意思。只是这是一条高风险高收益的路罢了。
LXC，包括openvz，在2013年之前，可不只是heroku等paas公司在用，有些公司内部都在使用，甚至包括我在内的一些公有云从业者也慎重考虑过用容器作为公有云的基础。
当然，还真有这么干的，Joyent，大概是除了AWS干公有云最早的了吧，可能比RackSpace还早点，就是基于solaris zone卖云主机的。Joyent的技术骨干是从SUN出来的，精通solaris，他们整了一个基于solaris的精简内核，专门用来跑zone，类似于coreos，叫做smartOS，基于这个做出了私有云软件SmartDataCenter。
说这些可能没几个人知道，但是鼎鼎大名的node.js很多人熟悉，就是Joyent开发维护的。
没错，LXC和openvz用在企业内部是很好的，非常好。但是限于LXC当时的管理工具欠缺，并没能大规模流行起来。它需要一个契机。这个契机就是docker，docker解决了LXC的管理问题。
电视剧总是那么相似，相遇、离别、重逢，受苦受难、遇到高人、报仇雪恨，IT圈的故事也逃脱不了这样的情节。Docker的故事，真的和OpenStack，包括此前的Linux等其他开源软件，有几分相似。
dotCloud把自己在容器上的工作成果docker开放开源了，开发者和小公司雀跃了：又来一个馅饼啊。这个馅饼解决了一些问题，让其他人和开发者免除了管理和开发工作量，这是次要的。
更重要的是，后来参与的开发者、小公司、大公司对docker的期待，远不止解决容器本身的管理问题，也不只是因为有一批人喜欢而从众，还有一个很多人很多公司没有说出的理由：容器是未来，干掉现在的私有云和公有云。
Docker 如此受欢迎，2013年10月 dotCloud 公司更名为 Docker 公司。2014年8月 Docker把平台即服务的业务dotCloud出售给位于德国柏林的平台即服务提供商cloudControl，2016年初 dotCloud被cloudControl关闭。而Docker公司开始全身心运营docker社区，并开展docker商业化。
Docker 迅速成长为云计算相关领域最受欢迎的开源项目，Amazon、Google、IBM、Microsoft、Red Hat 和 VMware 都表示支持 Docker 技术或准备支持。
据说，有 Linux 的地方，就可以运行 Docker。Mac上也可以，Windows上都有直接运行docker的Windows Docker 和 Nano Server，当然，这已经是windows版的了。
截止2016年初，Docker获得5轮1.8亿美元融资，推出了docker hub、docker trusted registry、dockertutm等产品，试图控制docker容器的注册、管理。在2015年上半年与openstack的论战之后，双方握手言和，以openstack支持docker管理告终。
Docker当然不甘心只是一个工具软件，也是要做产品、平台的，拿投资人的钱可不能做公益做开源啊。凡是有威胁的就要干掉，或者收掉。于是Docker收购Unikernels。
Docker为何收购Unikernels？既是看好，更是感到威胁
容器作为虚拟化技术的一种，在云计算出现之前就出现了。之所以在2014年前后流行，是因为大家需要一种与硬件虚拟化更轻量级的技术，来有效运转私有的基础设施。这个私有的，既可以在自家机房里也可以在公有云上。
在私有的私有的基础设施上，至少某些应用场景，Docker应为其轻量级，应用启动更为迅速，资源利用更为高效。但是，循着这个思路，Unikernels更进了一步。
我们先来看看怎么回事。
从操作系统诞生以来，它就扮演了一个应用和硬件之间的平台的角色，提供对硬件的控制。除了操作系统内核和基本的控制台，还有软件开发接口、语言运营时环境、语言库、输入输出设备控制，也需要支持各种古老的和新兴的硬件标准。它需要支持多用户、多进程、多设备并发。
虽然操作系统的的用途各异，有桌面的、内部IT系统的、有面向网络的，但操作系统的架构和模块基本相同，一致没有大的改动。但在上世纪90年代后期，Hypervisor被引入了主流的操作系统。Hypervisor运行于硬件之上，能支持多个虚拟机运行多个不同的操作系统。但这一变化，并未对操作系统的设计产生大的影响。每一个虚拟机仍然运行着一个传统的操作系统。
但是当Hyperfisor推动了云时代的到来后，通用操作系统的局限就更明显了。在云环境中，由于规模更大，负载被明显凤城了不同的类型：web服务器负责处理网络请求，数据库服务器负责数据库的运行和数据库访问，等等。这些服务器可能永远都用不上显示器、多用户、多进程。这些场景下的VM和OS的任务很明确，就是提供最好的存储、计算、网络性能。
开发者们开始质疑操作系统的的设计和架构：为什么一个web server 上要安装它从来用不到的软件？其实在此之前，Windows服务器就遇到过类似的问题。我们只需要能快速扩展和收缩VM的规模，VM约精简越轻量级越有利于这种弹性。但由传统操作系统构成的VM，只能勉强完成这个任务。
Docker所代表的容器恰逢其时。因为基础技术早已就绪，流行很快。因为能在同一个操作系统上快速运行多个隔离的轻量级的，容器基本解决了上述疑问。容器提供了应用程序所需要的一切，除了共用的操作系统内核，它封装了运行时环境、框架和库、代码、配置和相关的依赖。
容器大大削减了操作系统作为一个全能平台所承担的角色。容器之下的操作系统这时只需要承担一个飞航轻量级的角色：启动和控制容器。这时的操作系统更为专业化，而容器承担了运行各种不同场景所需资源的角色。
这种趋势催生了容器的Hypervisor的产生：CoreOS,RancherOS,Redhat Atomic Hosts,SnappyUbuntu Core,Microsoft Nano。他们是为了支持在其上运行容器而存在，没有其他的任务，已经非常精简。甚至Hypervisor之上的容器，有人又将其区分为操作系统容器和应用容器，应用容器就是只为单一应用为目标的容器。
到这里，微服务（MicroService）终于可以见天日了，终于能够使用了，而所谓的SOA、Mashable是不是能够换发新的光彩呢？
但这种精简、轻量级还没有到此为止，Unikernals出现了。在2014年初就出现了，那时docker刚刚开始崛起。
Unikernals将这种最小化操作系统的理念往前进一步推进。它是一个定制的操作系统，转为特定的应用程序的运行而编译。
因此，开发者能够创建一个极度精简的OS，只包含应用和它所需的操作系统组件。Unikernals是单用户、单进程、单任务的定制操作系统，它在编译时去除了所有不需要的功能，但包含了一个软件运行所需的全部堆栈：OS内核、系统库、语言运行时环境、应用，这些被编译成一个可启动的VM镜像，直接运行在标准的hypervisor上。
Unikernals让操作系统之上的容器又变成了一个操作系统，不过这是一个重新吧便宜的极为紧凑的，直接运行在hypervisor而不是精简的通用操作系统上的操作系统。Unikernel有着更小的尺寸，更小的可攻击面，启动时间也以毫秒计。Unikernals的论文在这里：https://queue.acm.org/detail.cfm?id=2566628。
不过，和docker一样，灵活带来的伴生问题，就是管理、监控、回溯、审计，有运维工程师说，docker就是运维的噩梦，那Unikernals可能是运维和开发者的噩梦？为啥，因为对应用改一行代码要重新编译整个镜像并部署，无法对一个Unikernals实例打补丁，也就是说Unikernals的实例是静态的。
Unikernals的例子包括MirageOS、Clive、OSv，目前都跑在Xen Hypervisor上。它有多小呢？一个MirageOSDNS镜像是200KB，而一个目前全球90%DNS使用的开源DNS服务器BIND镜像是400MB。而MirageOS DNS镜像的性能据称比BIND好45%。
咦？这不是嵌入式系统吗？Unikernals当然可以编译出镜像，运转在低功耗的设备上。如果Unikernals被移植到ARM平台上，开发者就可以编译出运行在ARM设备的hypervisor上的镜像。这将让嵌入式应用的开发更为容易。
那么，看起来，Unikernals虽然现在更像一个即可玩具，但是，不可否认，Unikernals有代替容器和虚拟机的可能，至少在某些场景下。既然容器比虚拟机在某些场景下更好，为什么更精简的Unikernals就不能代替容器和虚拟机呢？
有可能。而且这个理念和Docker代表的容器理念相符。于是，Docker收购了它。大家一起玩，一起干掉虚拟机。
Docker看起来无敌，前景光明。但是，道路还是曲折的。
大佬们是想干掉私有云和公有云的啊，你Docker公司守着这个热门技术不放，控制的紧紧的，我们怎么玩？不光是大佬，创业公司也不干啊。
首先发难的是CoreOS和谷歌。
CoreOS反水，Kubernetes和Mesos把docker打回工具原型
CoreOS首先不干了。
CoreOS原本是Docker初期的铁杆盟友，CoreOS可以说就是为docker而生的linux，它的唯一任务就是管理好docker。但是随着docker开始商业化，docker对镜像格式和代码收紧了控制，甚至建立开放平台存储docker镜像和认证，当然，还发布了docker管理工具。
那CoreOS的位置在哪里？当然，理由还是要像样一点的：docker的镜像格式不够灵活，工具链太庞大，我们要灵活而精简的东西。
于是CoreOS自己搞了一个容器：Rocket。本来嘛，大家都是基于LXC等工具的，这些工具都是开源开放，而且CoreOS也搞容器管理的，新搞个格式和管理工具还不是手到擒来。
当然，双方都承认，docker和rocket不是直接竞争关系。Docker是一个产品，并正在成为一个平台。Rocket只想做一个容器管理的组件。但是，双方还是分道扬镳了。
CoreOS一个人可没这么大的气势，背后还有谷歌撑腰。Rocket很快被Kubernetes支持。
Kubernetes的灵感来源于Google的内部borg系统，吸收了包括Omega在内的容器管理器的经验和教训。2014年6月谷歌宣布kubernetes 开源。谷歌想靠容器翻身呢？怎么能让另一个商业云公司控制最流行的容器。
Kubernetes算是一个与docker平台竞争的容器管理工具，自然首先支持docker，但是也支持竞争对手rocket。
但是Kubernetes也有一个潜在对手-Mesos。Mesos比Kubernetes出现得早，而且两者都深受谷歌的数据中心管理你项目Borg和Omega的影响。问题是，Mesos不是谷歌自家的，虽然属于Apache项目，但仍被商业公司Mesosphere，也是Mesos重要维护者主导。Mesos被称为数据中心操作系统，软件定义数据中心的典范。
Mesos既是计算框架也是一个集群管理器，是Apache下的开源分布式资源管理框架，它被称为是分布式系统的内核，可以运行Hadoop、MPI、Hypertable、Spark。使用ZooKeeper实现容错复制，使用LinuxContainers来隔离任务，支持多种资源计划分配。
Mesos使用了与Linux内核相似的规则来构造，仅仅是不同抽象层级的差别。Mesos从设备（物理机或虚拟机）抽取 CPU，内存，存储和其他计算资源，让容错和弹性分布式系统更容易使用。Mesos内核运行在每个机器上，在整个数据中心和云环境内向应用程序（Hadoop、Spark、Kafka、Elastic Serarch等等）提供资源管理和资源负载的API接口。
Mesos也不是也不是没有隐忧，Apache yarn似乎有一统分布式计算之势，MapReduce，Spark，Storm，MPI，HBase都在向yarn上迁移。当然，好在Mesos不仅仅是做分布式计算的框架。
Mesos也起源于Google的数据中心资源管理系统Borg。Twitter从Google的Borg系统中得到启发，然后就开发一个类似的资源管理系统来帮助他们摆脱可怕的“失败之鲸”，后来他们注意到加州大学伯克利分校AMPLab正在开发的名为Mesos的项目，这个项目的负责人是Ben Hindman，Ben是加州大学伯克利分校的博士研究生。后来Ben Hindman加入了Twitter，负责开发和部署Mesos。现在Mesos管理着Twitter超过30,0000台服务器上的应用部署。
Borg的论文2015年四月才发布：http://research.google.com/pubs/pub43438.html。Mesos的论文：https://www.cs.berkeley.edu/~alig/papers/mesos.pdf。Omega的论文：http://research.google.com/pubs/pub41684.html。这一回，谷歌论文发晚了，虽然也很有价值，但可能没有三大论文那么有影响力。
2014年7月，Mircrosoft、RedHat、IBM、Docker、 CoreOS、Mesosphere 和Saltstack 加入kubernetes。
2015年1月，Google和Mirantis及伙伴将kubernetes引入OpenStack，开发者可以在openstack上部署运行kubernetes应用。
2015年7月，Google正式加入OpenStack基金会，Kubernetes的产品经理CraigMcLuckie宣布Google将成为OpenStack基金会的发起人之一，Google将把它容器计算的专家技术带入OpenStack,成一体提高公有云和私有云的互用性。
同时，谷歌联合linux基金会及其他合作伙伴共同成立了CNCF基金会( Cloud NativeComputing Foundation)，并将kuberentes 作为首个编入CNCF管理体系的开源项目。
来，我们来看一下发起人：AT&T, Box, Cisco, Cloud Foundry Foundation,CoreOS, Cycle Computing, Docker, eBay, Goldman Sachs, Google, Huawei, IBM, Intel,Joyent, Kismatic, Mesosphere, Red Hat, Switch SUPERNAP, Twitter, Univa, VMwareand Weaveworks。
到此是不是大团圆了？所有跟容器有点关系的都来了。谷歌加入了OpenStack基金会，openstack上可以部署运行kubernetes，OpenStack支持docker，Mesos支持docker和kubernetes。大家互相都支持，谁能发展好，各自努力吧。这关系够乱的。
但是，容器的另外两个大玩家-亚马逊和微软，没有到场。没错，容器界就是要掀翻现有的云计算格局，当然不能让云计算老大和老二进来了。
谷歌纠集了一帮小兄弟，誓要利用容器浪潮，干翻亚马逊aws和微软azure。当然，谷歌也没有奔到准备靠一招制胜，暗战还有另一个战场：Serverless。
Serverless是云计算的决胜负战场？
2014年11月14日，亚马逊AWS发布了新产品Lambda。当时Lambda被描述为：一种计算服务，根据时间运行用户的代码，无需关心底层的计算资源。从某种意义上来说，Lambda姗姗来迟，它更像S3，更像云计算的PaaS理念：客户只管业务，无需担心存储和计算资源。
比如你要架构一个视频服务，你需要用一堆服务器，设计出一套上传、解码、转码的架构。但是，可能这套系统99%的时间都是空闲的。而使用一个Lambda function，你就不需要操心服务器和这套架构，当aws探测到用户定义的时间，比如用户上传了一个视频文件，Lambda自动运行响应的程序，结束后关闭程序。为客户生了时间和金钱。
Lambda识别Event的速度非常快，以毫秒来计算。它会在图片上传、应用内活动、点击网站或联网设备的输出等事件发生后的几毫秒内，开始运行代码，分配合适的计算资源来执行这个行动。它可以自动扩展到数百万个请求，如需要可跨越多个可用区。根据AWS Lambda是按计算时间收费，计费单位为100毫秒，可以轻松地把应用从每天几次请求扩展到所需要的任何规模的请求
而在此之前不久，2014年10月22日，谷歌今天收购了实时后端数据库创业公司Firebase。Firebase声称开发者只需引用一个API库文件就可以使用标准REST API的各种接口对数据进行读写操作，只需编写 HTML＋CSS＋JavaScrip前端代码，不需要服务器端代码（如需整合，也及其简单）。
Firebase是一个实时应用平台，它可以为几乎所有应用的通用需求提供支持，包括数据库、API和认证处理。数据库的特点是基于NoSQL的实时处理能力，并且允许直接存储JSON文档。Firebase具有双向同步的能力，在客户端侧，开发者通过Firebase的客户端库来支持典型场景的需求，比如屏幕刷新、离线时数据访问或者设备重新连接后的再次同步。Firebase对数据存储容量没有限制，最高能处理百万级的并发和TB级的数据传输，数据发生更改，同步敏感颗粒度基本达到10毫秒级别。
相对于上两者，Facebook 在2014年二月收购的 Parse，则侧重于提供一个通用的后台服务。不过
这些服务被称为serverless或no sever。想到PaaS了是吗？很像，用户不需要关心基础设施，只需要关心业务，这是迟到的PaaS，也是更实用的PaaS。这很有可能将会变革整个开发过程和传统的应用生命周期，一旦开发者们习惯了这种全自动的云上资源的创建和分配，或许就再也回不到那些需要微应用配置资源的时代里去了。
AWS的Lambda既不是最早，也不是最好，但它仍然是serverless最有影响力的产品，谁让AWS的用户多，产品全呢？
Serverless是未来吗？也许是。
Serverless能决定云计算的胜负吗？不能。
什么能决定云计算的胜负？
不仅Serverless不能，其他的产品、技术、项目、工具，都不能单独决定云计算的胜负。
从云计算初期的OpenStack和PaaS，到后来的Docker、Kubernets、Mesos、Unikernals，以及最近沸沸扬扬的人工智能，还有大数据分析，IBM甚至宣称Watson是它的云计算秘密武器，甚至可能即将光大的Serverless，都不能单独决定云计算的胜负。
它们都是优秀的产品、技术、项目、工具，但只是一项产品、技术、项目、工具，它们只能用来更好的服务客户，开辟新产品和加强已有产品，可以用来建立新业务或新公司。
IBM或谷歌也许能成为人工智能的王者，Docker也许能成为容器的领袖，Cloudera也许能成为大数据的领军企业，即使如此，这都是另一个领域的事情，是一种应用场景的事情，它们也许能也许不能成就新的行业，但都与云计算基础服务无关，与IaaS和PaaS无关，与公有云胜负无关。
这个世界从来没有独门秘籍。改变云计算格局，颠覆云计算市场的，不会是一个独门技术，也不会是一项秘密产品。
能决定云计算胜负的，仍然是远见、魄力、耐心。如果已经有了早行者，那就需要持续的创新，来蚕食领先者的优势。云计算是一个庞大的市场，从来不是一项技术、一个项目、一个产品的事情。
没有捷径。
微信公众号techculture
