回顾过去看IaaS的Next

IaaS层经历了多年的发展,这里也只能以我自己所经历的来进行回顾,之所以要回顾,是为了通过过去的发展,来看这个领域发展的动力,从而更好的创新,引领未来。

物理机->虚拟化阶段


阿里大概是在2010年开始用Xen来做虚拟化,推动这件事的是另外一位同学,问了下他,当时推进这件事最大的动力是两个,一是资源管理方式,在虚拟化前,都是直接用物理机,物理机的规格会不同,这会导致在LB上配置起来非常麻烦(我印象中记得以前我们在LB上开启权重,导致了一次严重故障,后来就不太敢用了),另一个是成本,站在外围,我看到的最主要是成本,不过说实话,以当年阿里的机器规模而言,尽管通过虚拟化把1台物理机虚拟成3个虚拟机,节省的机器比例看起来是非常高的,但由于盘子就这么大,所以这点成本在当时很难成为推进演进的关键因素,但资源管理方式那个确实是个推动的非常好的动力,因为那个是会影响稳定性的。

这件事我印象中当时的推进还是比较顺利的,主要的原因应该还是虚拟机和物理机还是非常像的,当时因为虚拟化这件事推进,我还写了淘宝当时比较统一的一版Java应用启动参数,后来在进展了可能两年后,阿里尝试把Xen换成KVM,但当时上线碰到了些问题,后来就没去尝试了,直到后来阿里云做虚拟化,阿里在虚拟化的技术掌控能力才真正的开始变得非常深入。

这个阶段的演进动力主要是为了更好的屏蔽机型不同,资源归一化,次要的是成本,现在的云用虚拟化最主要的还是为了提供多种类型的资源规格。

虚拟化->容器化阶段


2011年,我看了《Web容量规划的艺术》这本书后,觉得运行成本对于一家公司是非常重要的,从自己的技术角度来看,降低机器数是一个有效的方法,于是就去想有什么办法可以降低机器总数,找人拿了机器的一些数据后,看到机器的整体利用率是非常低的,于是想既然一虚三利用率还很低,那能不能在一台机器上跑更多呢,了解了下,如果用虚拟化的方法的话,内存超卖不好弄,所以就得找另外的办法。

和多隆说了这个想法后,多隆也很感兴趣,于是就来摸索有什么办法,最早的时候尝试了直接在物理机上跑多个业务进程,结果碰到了各种冲突的问题,例如典型的监听端口冲突,更麻烦的是运维,因为出问题了,不知道哪个应用,查起来特别麻烦,于是觉得直接跑进程不行,还得有一定的隔离性,这个时候尝试了各种黑科技,例如自己改sshd、各种命令行对应的背后的函数,确保可见的隔离性,但这个方法的最大问题是无法穷举,所以总是有各种问题。

突然有一天多隆和我说有个叫Linux Containers(LXC)的东西,好像可以很好的满足需求,于是开始试验,基于LXC包装了我们自己的代号叫T4的容器,我们把这个东西改造的和虚拟机特别像,对于用户来说登录到T4的容器,所有的感受和虚拟机几乎是一样的,这个方案从落地执行角度来说就比较好推进了,毕竟对用户来说几乎是无感的,并且到了2012年,机器资源的申请也变的比较紧张,T4可以用更少的物理机提供更多的“虚拟化”资源,比较受用户的欢迎,到了2013年,交易的核心业务开始切换到T4后,后面的推进就越来越快了,于是阿里就此迈进了IaaS层主体是容器化的时代。

这个阶段的演进动力主要是对规模化后成本控制诉求的预判。

容器化阶段->容器+Docker镜像阶段


2015年,Docker火爆,我们也开始尝试将Docker的镜像+T4的容器进行结合,在这个尝试的过程中,我们切实的感受到了容器+镜像化给运维带来的巨大改变和帮助,这里要多说几句,当时我们对Docker的镜像机制能带来多大帮助一直存有质疑,争论非常大,所以从这件事来看很多东西还是得试试才知道,对于应用而言,在没有把容器+镜像结合起来以前,部署方式通常都是先申请机器资源,然后在机器资源里部署应用,但应用由于有各种语言、架构,所以部署的方式通常会有很大的区别,这个时候对运维类型的系统就非常复杂了,但容器+镜像这种方式使得交付应用这个过程标准化,把交付的这个概念从分离的机器资源到应用部署这两个过程合并了,这对实际业务而言才是更加合理的,有了容器+镜像这种方式后,运维的变更就可以用一套统一的运维平台来标准化了,当然,这也不是Docker首创的,Google家很早前就是这样,但可惜Google当年没开源,导致镜像的标准化现在基本是Docker的格式。

容器+镜像这种站在交付的最终产物诉求的思想延伸到了后来接下去的一些产品的进一步创新中,例如Terraform、Helm等。

这个阶段的演进动力主要是更好的满足交付物的诉求,而这种的结果就是在下层的东西会越来越不可见。

容器+Docker镜像阶段->统一调度阶段


这几年阿里除了在继续推进容器+镜像化(这个产物已经开源:PouchContainer)外,另外一个很大的演进是推进统一调度,推进这个的诉求主要是成本,容器化后可以看到机器上就算能运行更多的容器,但成本下降的还是不够,因此继续进一步看,非常显然的问题还是资源利用率不够高,在做T4的阶段,就听说了Google的Borg,Borg最重要的是通过把资源都归拢在一个池里,并且通过在线任务和离线任务部署在同一台机器(混部)上来大幅提升资源利用率,统一调度可以用一个非常简单的指标去评估做的怎么样,就是平均的资源利用率,Google家大概应该在50%,阿里目前开启了混部的集群一个月下来的CPU平均利用率大概在40%上下,这个阶段的方向是非常清楚的,但要做到这样的程度,对基础设施、内核的改进、调度系统的建设都有很高的要求。

这个阶段的演进动力主要是成本的诉求。

IaaS的Next


以上的各个阶段的演进的具体技术细节在阿里系统软件的公众号里都有分享,感兴趣的同学们可以去找找看。

回顾上面几个阶段的发展,我们能够看到,IaaS的发展/创新主要有两个非常明显的点:

  1. 成本IaaS层随着规模的不断增大,成本的优化动力会越来越大,从目前的状况来看,怎么更好的优化资源利用率仍然是IaaS层技术创新的核心动力,这个对于云厂商而言,一方面是优化自己的利用率,另一方面是给用户更好的提升资源利用率的产品;软硬件结合也是目前看到的另外一条很好的路径。
  2. 被屏蔽从物理机->Xen/KVM->容器->K8S/Terraform/Helm,可以看到非常明显的趋势是IaaS越来越被标准化接口屏蔽,未来上层会越来越不关心IaaS的这个具体的运行单位是什么(但始终会需要安全、资源的隔离性,至少是可见的隔离,以及越来越强调的启动速度),从目前的状况来看呢,具体的运行单位在3-5年内应该还会是容器,但容器下面是什么就出现了非常大的优化机会,从硬件,到虚拟化,到操作系统,这两年无论是Google,还是AWS,都已经开始展现了下面这几层的优化创新(gVisor、Firecracker等),但现在并没有霸主出现,这种机会就像是虚拟化刚诞生的阶段,是多年才能一遇的。

按照这样的创新路线下去,技术门槛太高,未来IaaS这层大部分企业都没有能力自己做,不像以前弄个Xen或者KVM,大家差距就很小,以后还是直接用云就好了,毕竟人才也多数会被这些公司垄断掉,云的公司一定会在IaaS这层继续加速演进,并且由于动力大,我相信会比前面很多年IaaS层的技术演进速度快非常多,对云类型的公司而言,比拼对IaaS层方向的掌控力会至关重要,我的建议是围绕在优化资源利用率、软硬件结合、从成本/启动速度等角度思考彻底重写容器下的各层三大方向来进行IaaS的优化和创新,当然,其实方向很多人都能看到,但是否能坚定的在方向上走下去最终会成为分水岭,这也同样意味着方向的判断就非常重要了,毕竟技术的创新不像业务模式,它需要更长的时间。

最后用一张图总结上面所写的:


欢迎关注我的公众号hellojavacases,

聊聊编程能力的高级进阶,

聊聊系统设计,

聊聊技术方向,

聊聊职业生涯的发展。

开发者生态,未来云的胜负手?

过去一年云厂商在开发者生态上的争夺开始变得激烈,为什么会出现这样的现象呢,是不是开发者生态,已经成为了云这场战争的胜负手呢?这篇文章就来探讨下这个话题。

事件


我们先看看在过去一年发生的几起重要的开发者生态的事件:

  1. 微软75亿美金收购Github,Google领投1亿美金Gitlab,使得Gitlab估值突破10亿美金;
  2. Coding获腾讯云一亿元战略融资;
  3. 开源厂商 Vs 云厂商开源厂商和云厂商在2018年发生了非常多的状况,关系在开始变得微妙,有几种现象出现:1). MongoDB、Kafka、Redis纷纷修改开源协议,限制云厂商,Neo4j企业版不再提供免费下载;

      2). 微软在2018年非常明显的加大了在开源的投入,上面说到的收购github,还有例如加入OIN,开源的VS Code在2018年是github上吸引到最多contributor的项目;

       3). Pivotal、ElasticSearch上市,目前的市值都超过50亿美金,Confluent(主要产品Kafka)、Databricks(主要产品Spark)宣布完成新一轮融合,市值均突破25亿美金,国内的话主要是Pingcap完成的新一轮5kw美金的融资,致敬下,作为技术人员对在国内能创办出Pingcap这样的技术产品公司无比佩服;

        4). 阿里巴巴9kw欧元收购Flink母公司,微软收购开源公司 CitusData(PostgreSQL 商业化的Startup);

海外三家云厂商的观点


再来看看海外几家云厂商自己在开发者生态这块传达的信号:

  1. AWS”大概12年之前,我们深知云将给软件带来翻天覆地的变化,我们创造了AWS。一直以来AWS希望与软件开发者密切合作,打造出一个现代化的软件开发框架。而不是告诉客户,你们需要什么工具。在AWS的信念中,我们认为真正知道软件应该如何开发的只有一个人,就是客户本人。”这是AWS CTO在去年中国的AWS Summit上讲的,其实在其他很多场合,尤其是每年的AWS:reInvent上也都会不断的表达这个观点,就是AWS和软件开发者是在一起的,AWS的会议吸引了无数顶尖开发者参加和关注,毕竟里面讲的很多都是未来的软件发展趋势。尽管Amazon给人的感觉在开源上贡献不大,但在技术发展的引领上我觉得还是起到了不小的作用的,在开发者群体中的认可度也足够高。
  2. 微软
    微软作为一家操作系统起家的公司,在开发者生态上一直就非常重视,而随着云的发展,感觉更进一步了,除了上面的github收购外,微软也开始非常大力的加大在开源上的投入,可以说,微软对开源的贡献是非常有助于推进这个世界技术的发展的,微软之前的形象开始有了不少的扭转。
  3. Google

       Google早期通过发表论文,在开发者群体中得到了非常高的认可,同时也非常切实的影响了世界的技术发展,例如大数据领域。

       近几年Google通过各种开源,更是形成了不错的开发者生态,无论是K8S、TensorFlow,都对世界技术的发展起到了很大的推进作用。

       Google Cloud的CEO最近还公开的讲”谷歌云:我们对开源的态度与AWS不同“来怼AWS,讲的核心的一段是”一直以来,谷歌云采取与开源社区合作的方式,而不是在自己的云平台中使用并出售开源技术。“,结合上面的开源厂商 Vs 云厂商的一些事件来看这段就更明白了。

关于开发者生态,我的观点


从上面的这些内容可以看到的现象是,各家云厂商都在通过开源、收购等方式加强对开发者生态的投入,拥有众多开发者用户的开源软件厂商在资本市场得到了很好的认可,开源厂商和云厂商由于利益上的冲突,关系尚待理清。

开发者生态为什么会发展到今天的这个局面,必须说说云的发展趋势。

最早用户对云的使用基本是纯粹的使用机器资源,和以前的虚拟主机等其实没有太大的区别,而发展到今天,几个大的云厂商强大的资源集约形成的规模效应,更是让用云的机器资源这件事成为了不需要再纠结的点,尤其是对初创公司而言。

随着对云机器资源的使用后,慢慢的开始有了用户开始使用更多的云的软件服务,例如存储、数据库等,在美国这个趋势非常明显,越来越多的公司画的技术栈中有越来越多的云软件产品的出现,下面这张图是Next Platform上对于AWS中计算、存储、网络和软件收入的分析:

可以明显看到软件这块越来越高,意味着越来越多的用户除了使用云机器资源外,开始使用云软件服务。

从对客户的价值上来说,越多的使用云软件服务,也就意味着自己在这方面投入的人员可以大幅减少,更加专注在自己的业务上,这一点随着经济形势的变化会更加的重要,而站在云厂商角度呢,客户使用越来越多的产品当然是更好,所以从趋势上来说,越来越多的使用云软件服务会加速。

而从技术趋势上,看到非常明显的两点:

  1. 通过PaaS屏蔽IaaS,对客户价值而言这是非常有益的,同时对云厂商来说也意味着IaaS层拥有了巨大的创新机会,以及不透明后带来的利益机会;
  2. No Lock-in,由于越来越多的使用云软件服务,客户心里上会非常担心Lock-in的问题,尽管我认为不会有多少客户真的同时部署在多家云上,但一定会需要具备这个能力,就是可以很简单的进行切换。

从这些趋势来看,也就意味着云的竞争进入云软件竞争的时代,云软件的用户群体是开发者(当然,有另外一种观点是通过强有力的SaaS软件直接服务最终用户,但我认为那样覆盖的面始终是有限的,云厂商自己很难去做好各种SaaS,只能是构建好一个平台,让上面有更多的SaaS厂商),并且软件和其他很多产品不一样,尤其是那些渗透到代码中的API,通常来说切换的代价很高,例如开发框架用了Spring,要想切换成别的很复杂,所以这层的竞争非常重要的一点就是谁能拥有对应最核心的非标准化领域的最多的开发者用户,也就是开发者生态。

要想获得开发者用户,和2C的很多产品竞争完全不同,这个领域基本不是靠砸钱就能获得用户的,很重要的三点是:

  1. 开源触达通过开源,让更多的开发者用户能即使不使用云软件服务的时候也能接触到,从而培养大量会用的开发者。同时借助开源,也可以更好的吸收各行各业的需求,使得产品更加的具备通用化的能力,覆盖更大的规模和更广的场景。怎么做好开源,对中国的公司是很大的挑战,这里面的套路非常的深。成功的开源软件因为在相应领域覆盖了大量的开发者用户,当在云上推出相应的商业服务时也会自然的收获用户,但由于目前这些利益基本都被云厂商拿走,这让相对应的开源厂商的努力得不到回报,导致产生矛盾。关于云厂商和开源厂商的关系,我觉得在2019应该会进一步明晰,一方面云厂商自己会加强在核心领域的开源,触达更多的开发者用户,另一方面会通过收购去补强核心领域的能力,很多人可能觉得这样不好,但我还是坚定的认为正因为有商业利益的诉求,这样的开源反而才能更为持续、健康快速的发展,对这个社会的发展而言是更有利的。开源对这个世界的技术发展、业务创新是起到了很大的帮助的,真心希望这个世界越来越多的开源,而不是越来越封闭。
  2. 技术领先在开源界中,同技术领域同质的产品基本只会留下一个,必须保持持续的技术领先,否则就算一个阶段领先,也很容易在下一轮技术迭代中格局被改变。
  3. 工具触达

       触达开发者用户的另一个很好的方法是工具,开发者用户群体最大公约数的工具是IDE,这大家就很容易看懂为什么微软开源vs code,并且那么重视,另外一个方面的工具就是开发流程方面的,代码是整个开发流程流转的核心产物,这也是Github巨大的价值。

综合来说,我认为开发者生态是未来云的胜负手的关键,从上面也可以看出,要做好开发者生态并不简单的是一件运营的事,而是产品规划、技术创新、社区建设、工具建设、运营等一起的事,这也是为什么我们看到海外的几家云公司是把这个上升到非常高的高度的原因。

最后,对于中国做这块的创业公司而言,我认为以下的两个方向是非常好的时机点:

  1. 社区一个优秀的开发者社区对形成繁荣的开发者生态是至关重要的,无论是问题、讨论、线下活动等,国内现在好像已经基本没有优质的开发者社区了,前几年还是有几个的,可惜当年做社区的同学都太难获得利润,导致很难运转下去,但到了今天这个局面下,我觉得会很有机会,不过要做起一个社区必须有长时间投入的打算。
  2. 开源技术产品技术领域需要的产品其实是非常多的,即使是云厂商自己,也很难去全部覆盖,因此这个方向的机会空间还是不错的,首先需要的是对相应有一定规模的技术领域的洞察,影响力,同时需要长时间的投入和经营。

衷心希望看到国内在为程序员这个行业群体服务的创业越来越繁荣,那样一定会让中国在IT技术层面逐渐对世界产生越来越大的影响力,更好的推进世界技术的发展。


欢迎关注我的公众号hellojavacases,

聊聊编程能力的高级进阶,

聊聊系统设计,

聊聊技术方向,

聊聊职业生涯的发展。