2020年中国云原生用户调研的十二个要点
发布日期:2021-06-30 20:21:02 浏览次数:2 分类:技术文章

本文共 6515 字,大约阅读时间需要 21 分钟。

在这里插入图片描述

来源声明:本文诸多信息来源于云原生产业联盟,相关版权归云原生产业联盟所有,本文内容仅在此基础之上对于调研报告的内容进行个人解读与分析。
国内第一份云原生用户调研报告在上个月的云原生大会上进行了发布,在一个月后的今天,一个周六的早上,认真读了一遍,整理了一些要点,不敢独享,发出来与大家共享,个人观点,如有雷同,纯属巧合,欢迎人格攻击以外的一切批评指正。

要点总结


数据来源:数据通过在线调查方式获得,有效问卷共计487份。行业分部主要如下所示:

在这里插入图片描述


要点1:互联网目前仍是云原生技术实践最主要的推动力

分析解读:487份调研问卷虽然稍显单薄,还是能够管中窥豹了。比如还是可以看到互联网行业是目前最重要的技术实践者和参与者,另外不同行业对于云原生也显然都进行了不同程度的参与,这份报告中暂时并未对于各个行业云原生践行程度进行分析,在后续的分析中如果添加,相信对各垂直领域行业内对标有很好的借鉴意义。问题再进行深入思考一下,为什么互联网对于云原生有如此的热度?个人认为主要有如下两个因素:

  • 互联网企业大多对于技术有更大的敏感性和实际的需求,业务受新技术的影响最大,目前业界普遍认为云计算之后的下个十年将会是云原生的时代,自然对此会趋之若鹜紧追不舍。
  • 互联网企业历史技术负债相对于其他动辄大几十年的Legacy System(旧有系统)的影响较小,新技术推动的成本和影响都较小,阻力自然小的多。

要点2: 💰钱景明朗,企业在云原生技术领域发力投资的事实越来越明晰

在这里插入图片描述

分析解读:有9%的企业在云原生方向投入(💰)超过50%,虽然此份报告并没有列出此9%的具体行业,相信互联网企业大概率会占到较大比例。另外接近2/3(64%)的受访者的将费用控制在30%以下,说明这个比例中的大部分企业已经开始试探着实践云原生技术,建议云原生产业联盟后续的分析中对此部分进行进一步挖掘,比如哪些行业和细分领域,当然最好有多一些问卷样本的支撑。

在这里插入图片描述

💰钱花在哪里,自然也非常清楚,搭台子、建团队从硬件到软件都需要资金的投入,用于技术研发和用于运维的占的比例最高,前者的目标主要希望技术的红利用来挣钱,后者则重点关注与省钱,你花的是你未来挣得钱或者是未来省下来的钱是每一个客户最希望从技术咨询那里听到的内容,因为这是客户内心深处最期待的事情,长期不用花钱就把事情给做了,立场不同,不必置评。整体来说还是可以看到大部分还是在进行云原生相关的初期建设。


要点3: 中小规模实践为主,适应混合基础设的架构将是过渡阶段的必修课程

在这里插入图片描述

分析解读:可以看到集群和结点的规模大致都是以中等集群为主,76%的用户纳管集群在500结点之内,46%的用户容器规模低于200结点,这个更大程度可能是因为各行业当前的数字化业务规模和市场需求所决定的。另外值得关注的是如下两点:

  • 10%的用户纳管集群规模在5000结点以上,9%的用户容器规模大于10000,随着集群规模的扩大比率却突然反常升高,这个原因也大概率在于本次问卷中头部互联网企业参与的比率,毕竟集群规模大于5000结点的应用目前阶段很多都是大家耳熟能详的企业,加之问卷的数量较少以及互联网企业的比例过大,这些可能就是相关的原因。不过此9%或者10%的比率和之前资金投入9%的企业有一定程度的契合,建议后续进一步确认一下关联性。
  • 云原生的实践中,纳管集群中包含虚拟机和模金属服务器这个在一定的阶段有可能将会是一个短时间内过渡趋势,这个过渡时间可能会很长。三年前我在 中就曾经列出过一个类似看法:混合云的基础架构将成为短时间内的趋势。实际上这里面有成本、旧有系统和安全的诸多因素的制约和影响,旧的基础设施在资本的要求下需要发挥更大的能力,从而我们技术人员必须给出对应和解决的方案。

要点4: 多云部署已成趋势,云间融合数据交换需求已现

在这里插入图片描述

分析总结:从结论上看,大体有3/4的用户已经在使用或者未来1年内计划采用多云/混合云架构,1/4用户没有相关计划。而多云部署之下,多云独立部署且云间数据交换需求量大的比率达到20%,这个数据考虑到3/4的比率中除去计划中的和一部分尝试中的,这个比率已经不低。云计算提供商本身也正在不断的发展,各厂商之间显然目前缺乏统一对数据的融合进行管控的方式,毕竟vendor lock或者客户粘合度是每一家云服务提供商内心最渴望的事情。而在这种情形之下,较大的云间数据交换需求有20%已经是一个很大的进展,如果这个数据真正能够体现目前的状况而不是互联网企业和头部企业在本次调查中的影响,后续显然将会倒逼云网融合在数据和安全等多方标准的快速落地实施,如果这个比例只是云厂商自身能力的建设阶段就另当别论了。数据交换是一个非常不错的调查点,建议后续在此基础上对于数据交换的用途进行细化调研,同时数据的交换是实时性还是非实时性的也会对架构产生很大影响。


要点5: 容器化技术红利释放成为驱动因素,安全、成本与陡峭的学习曲线仍然是当下主要阻力

在这里插入图片描述

分析解读:用户认为云原生技术的价值主要体现在资源利用的提升以及弹性伸缩效率上,这确实是容器化技术红利释放的直接效果。另外,在提升交付效率、简化系统运维等方面也可以看到容器化的背影。我习惯于目前将目前云原生技术内核用三大特性来总结:容器化、DevOps和微服务(Pivotal的四大特性中还有一个持续交付,而持续交付显然和DevOps纬度有一定重叠,而三个特性则更加容易理解、比较和交流),由于微服务框架基于Spring Cloud/Dubbo等的框架几乎一统天下,Service Mesh很多企业尚存疑虑,当前已经稳定能够直接释放红利的显然就是容器化,这也是效率提升和成本降低的推动器。而用户的疑虑,在旧有系统的改造和迁移成本、方式等方面随着云原生的普及将会进一步凸显,对于使用中的安全和新技术的技术栈的复杂性,这也是基本不会消去的,因为每一种新技术的出现都会出现这种情形。安全也永远是重要的关注点,但是很有价值的一点在于15%的“应用价值不明显、投入产出有待评估”,结合前面的调查,毕竟接近3/4的企业资金投入都大于总体IT投入的5%,省下的1/4也是小于%5,如果是已经有资金投入,但是却未收到效果,相关的原因可能是需要我们重视的,因为这可能是花钱学习到的反模式,建议后续进行进一步的分析,为何有待评估,因为这基本上就是说这钱花的不清不楚的意思。


要点6: 发布频度和周期在能力提供上不再是限制要素,用户自身节奏和能力需要同步提升

在这里插入图片描述

分析解读:在今年年初的一份全球对标的分析中,也看到了类似的企业能够进行按需部署的比率已经很高,加之云原生的整个技术栈之下,DevOps已经不再是一种理论或者是最佳实践等在纸面上的程度,而是必须落到工具和研发过程之中的内容,所以按需部署基本上已经是云原生技术栈下必备的能力,无论是购买还是利用开源都可以很快的落地实施。能力已备的情况之下是否自动发布还是手动发布还是按照指定的策略进行发布,都在使用者的一念之间,而这一念则跟使用者企业的内功有关,跟业务需求和市场的要求紧急程度、代码的质量、测试缺陷的收缩率、非功能性因素在架构上的完成程度等多方面有关。总之,这已经不再是一个没有办法打开部署那堵墙的时代,而是钥匙已在你的手中,可以根据你的需要开启,使用者可以将更多的精力回归到软件开发周期中的其他基本要素的质量控制上了。


要点7: 容器化广泛采纳,Kubernetes和Docker仍是当前主流

在这里插入图片描述

分析解读:生产环境中容器技术的使用已经超过60%,Kubernetes在容器编排的事实上的标准也继续影响市场的地位,Kubernetes基本上已经形成了类似Linux内核和发行厂商的整体生态,成为了继Linux之后另外一大生态,社区繁荣、周遭生态和开源百花齐放,是云原生技术爱好者们的福音。容器运行时Docker比Kubernetes还占有着更大的比率,多元发展趋势已显,Docker仍是主流选择。

PS:从2013年Docker诞生到现在,容器化的大开大合让人常有物是人非之感。虽然只是刚刚一个七年之痒,但Docker已死的言论都不知道起了多少次。Kubernetes高门大户,很难撼动,但似乎只是把LXC封装起来的Docker成为了大家眼中钉肉中刺,动不了K8S还动不了你么,大概这就造成了容器运行时多元发展,Kubernetes独自优秀的局面的重要原因。对于市场的追逐使得昔日盟友Coreos相爱相杀首先发难,取代Docker的豪言壮语言犹在耳,rkt多年前已经成为了K8S中第一个退出的项目。似乎,Docker在风雨飘摇之中悲壮地问,还有谁?一片回声,还有我,还有我,我们都是容器运行时。那个,个子最大的小子,你是哪来的,Containerd?哦,一家的,你坐下,你挡住我看元直的背影了,咦,好像没人了,元直呢,podman们呢,看着空荡荡的竞争环境,Docker表示十分怀念rkt,但实际上有很多rkt,只是个子很小而已,对于只有7岁的Docker来说,下一个7年将仍然很漫长。开个玩笑,虽然对陷入竞争中的重复制造轮子的企业来说很痛苦,对于技术爱好者来说,宫斗继续真的觉得很好,期待一定不要在一起。


要点8: 容器化落地场景多种多样,安全仍是重中之重

在这里插入图片描述

分析解读:容器化带来的红利在各个场景展开,通用型的平台和承载业务的微服务都是重点内容,前者是初期阶段的重点,后者是持续整个云原生的关键。容器的安全成为用户的最大担忧,相关的担忧也不无道理,容器还在蓬勃发展,安全的问题自然更加凸显。除了技术复杂度和技术支持力度不足之外,在云原生的技术栈中,安全将会成为一个非常重要的点,但是当我们将目光投到CNCF的那张非常复杂的图中,那张包含了众多"Kubernetes发行厂商"的图中,安全相关的vendor还未真正成系统成规模,安全是最先被提到但一般是最后才会被真正关注和落到实处的点,毕竟只投入大量资金做风险控制,在生存空间本来就不足的早期,推动此事多少有点费力不讨好。

PS: 短期内缺钱缺技术要效益要速度的早期云原生实践阶段,安全方面请牢记16字真言:口头重视,内心侥幸,每天拜佛,一日不落。


要点9: 微服务已渐趋主流,稳定成熟框架选择不足

在这里插入图片描述

分析解读:从结论来看80%的用户已经计划或者使用微服务,考虑到60%的受访者为互联网领域,结合传统领域,整体比率应该会有所下降。另外微服务改造中有六成是基于旧系统进行改造,此部分在传统领域中可能比率会更大。但是如何具体实施可能会Case By Case地遇到不同的难点,其中最主要的问题之一就是微服务框架,虽然说可供选型的微服务框架较为丰富,但是加上稳定成熟的过滤词之后,就会陷入无型可选的尴尬境地。Java系的架构稍微幸运,Spring Cloud或者基于此技术体系的Dubbo等几乎一统天下,但是Spring Cloud的侵入性一直是Service Mesh所攻击的,多语言的支撑不足、能力下沉和复用复杂。除去Spring Cloud只好转投Service Mesh,服务网格以Istio为代表,调查中也非常清晰的看到了占到19%的比例,而Consul也有17%倒是一个稍微意外的结果,至少从今年这份调研报告来说,Istio和Consul在用户心中,那时一个比重,这从侧面也看出了Istio当下叫好不叫座的尴尬情形。总结一下,稳定且有成熟社区的Spring Cloud只在Java系有所深耕,容器化下微服务多语言无侵入的新一代微服务框架的Service Mesh显然目前主要更多地是头部互联网企业在力推并进行能力平台化,所以这也就造成了第三大比例中的另外一个19%自研的产生,自研有19%的原因可能有两个,一是所有自研的项目都不知道市场上已经有成熟的轮子而自己闭门造车,另外一个就是目前的主流框架无法适应,这是现状用脚投票给出的结果,稳定成熟框架不足以支撑当前的选型,19%企业无型可用,自创轮子来进行微服务改造,所以整体微服务已趋主流的结论是可以得到支撑的。整整希望这一切,在明年的Istio等实践中能够有所改善,三年磨一剑,该可以显露锋芒了。

要点10: 云原生技术推动过程中反向康威定律可能发力,请系好安全带

在这里插入图片描述

分析解读:微服务与开发和运维效率以及容器化的相互支撑是一个横看成岭侧成峰的话题,也有很多解读是从微服务的落地是需要DevOps或者容器化的支撑的,不过互相成就相得益彰可能就是这三者的关系,也是当前云原生核心技术中需要重点关注的事项。需要注意的反而是26%的“优化了企业架构”作用。早期阶段我们在做DevOps咨询的时候一直不敢过多触碰的就是此处,康威定律的反向影响就是技术本身会对组织结构有什么样的影响,现在是DevOps了需不需要改成适应DevOps架构的组织结构,一个团队要不要砍掉一个处长。同理,现在微服务了,要不要改成适应微服务架构的组织结构,考虑到此部分结论会引起不必要的争执,不在此处进行展开了,但是我个人的观点看起来此处26%的作用非常像康威定律的反向作用,毕竟我们都在同一条奔涌的河流中。

而在微服务架构开发中的挑战中提到微服务治理能力不足是最大的挑战,结合前面我们提到的无型可选,技术改造不知何去何从的情况下,发现微服务缺乏拆分的标准规范,到底多大是大,很快可能会上升到规范标准统一的角度,而以我今年曾经参与过的架构咨询项目为例,在调研中关于微服务的粒度拆分是否影响敏捷开发与交付的效率等问卷的大部分反馈是不会,所以这可能是一个值得探讨的问题。
在我们大弹微服务架构的时候,却只有Java系的Spring Cloud大体可用,Service Mesh有待观察,Server Less尚在早期阶段,技术和架构上心里没底,转而去确认组织结构是否适合,拆成多大多小标准不清,行业案例不足,反过来问一下技术和架构人员和自己,即使是组织架构要什么样的给你什么样的,拆成多大多小只要维护起来效率不影响你随意发挥你就是标准,别的案例也顶多给你一些信心而已,别人做好咱们就一定能做的好么,不能。所以,关键上的技术要点没有解决,关键的阻碍性的技术问题没有解决,合适的框架没有找到等细节没有考虑清楚,在这个阶段强推的话,最终反省的时候可能会拿这些不是根本答案的答案来负责了。总之,要小心康威定律的反作用的影响。

要点11: 无服务器架构仍在逐步升温

在这里插入图片描述

分析解读:从调研结果来看,几乎已经有一般的受访者表示已经在实践无服务器,与个人所接触到的当下阶段项目的情况来看这个比例基本和现状不太一致,可能是受60%的受访者来自互联网企业有关,在实际的生产环境中已经有接近30%的企业在使用无服务器技术,而这其中15%是核心业务,大概率是互联网头部企业自身在eat own dog food的过程,公有云的无服务器以阿里和腾讯为主,而私有云的无服务器架构则处于一个百花齐放的阶段,但是Kubernetes则几乎是必选项。不过,整体来说,无服务器架构正在逐步升温确实是一个明显的趋势。


要点12: 无服务器的前景可能是光明的,但现状的推进还是困难的

在这里插入图片描述

分析解读:无服务器架构目前阶段的缺点像优点一样明显,比如在部署过程中的挑战,可以看到从测试、监控到配置和打包,几乎所有的阶段都有隐忧,以至于最近有个观点是在线的IDE能够解决这个问题,而一个集成开发环境能够包打天下真正解决这个问题还是值得推敲的。所以在采纳无服务器技术考虑的第一要因就是部署成本,另外关于自动延时这样具体的问题成为无服务器技术采纳时的考虑问题,确实反映了当前的无服务器技术在这些方面需要进一步的提升。道路可能是光明的,在用户真正接受之前,能否成长到真正让用户希望接纳是决定无服务器技术曲折路程的长短的关键点。

其他

作为第一份国内云原生的用户调研报告,从中我们看到了很多内容,而对于一些其他的细节,比如9%把资金的50%的用户到底到底是怎样的情况,以及统计到底能不能真正反映市场的现状,这可能需要结合后续的调研进行观测、总结和分析。

转载地址:https://liumiaocn.blog.csdn.net/article/details/109801259 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:Python基础:使用neuralart进行图像处理
下一篇:SVN基础:使用http方式使用svn服务

发表评论

最新留言

不错!
[***.144.177.141]2024年04月08日 17时17分47秒

关于作者

    喝酒易醉,品茶养心,人生如梦,品茶悟道,何以解忧?唯有杜康!
-- 愿君每日到此一游!

推荐文章