从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(二)

简介: 快速学习从 KubeVela 谈起:云原生应用交付会怎样发展

开发者学堂课程【云原生技术趋势与行业发展解从 KubeVela 谈起:云原生应用交付会怎样发展】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/1035/detail/15146


从 KubeVela 谈起:云原生应用交付会怎样发展


二、与原生时代的 DevOps 技术

我们也讲到了第二个部分,就是原始时代的devops技术,如果我们仔细的思考我们刚刚的诉求的话,其实我们可以看到,它一共就分三个阶段,第一个就是构件,然后是交付,然后运行,我们很容易想到,我们在这个过程中呢,要控制认知要简化我们的这个体验,同时他现在的这个云原生天然是这个混合的环节,就是你可能不光是使用一个asp集群或者说不光是使用一个运营商可能还有一些自己的公司的这种自建的一些集群或者技法同时还会有一些边远的一些环境所以它天然是存在不同的环境,同时今天是容器之前可能还有后续的业务,明天可能会有service或者方形的业务那其实他背后运行的程序的工作负担也是多样化的,所以你会有不同步,多种多样的这种交付的诉求,对于基础设施的运行时的诉求,同时他应该天然的支持这种混合的环境,比如说你可能要跨不同的集群调度,不同的云去做部署去做等等可能会需要一些环境的弹性能力,比如说你在自己的公司机房里面可能一共就五百一千台机器这个时候你的业务快递,618双11这种活动,那这个时候你的用户快速增长,你发现你的公司里面的机房扛不住了,那这个时候应该快速的迁移到云上,云上,比如说像阿里云的这种资源,能够帮你提供的服务,就会有些跨越的这种部署的能力。

image.gif所以其实这个也是一个很大的诉求,就是在现代应用上面可能有些跨越的,同时,我们可以看到AI生态里面有上千个这种服务,对吧,我们不可能置之不理吧,必然要有一个很好的能力,能够把这些生态链的能力呢,很好的集成进来,所以我们自然就总结出了这四大特点,四大原则,第一部分就是要控制认知部分,第二部分,是要满足现在的这个应用的需要。我们来看四大四大这个原则,他的具体是。

image.gif首先就是第一条原则,所谓中心呢,大家也可以认为是以开发者为主题,或者以这个软件开发的这个开发企业效率为中心,这种角度去思考,那如果我要有一个好的开发体验,一个开发效率,自然离不开一个清晰的这种命令行工具,简单的一个配置,给你开一个产品的意外,所以我们要做这样一个平台,必然要有一个好的ci,这一点可能大家应该也毋庸置疑的,所以为什么要强调这一点,因为现在有很多的基础软件,其实他们不具备很好的运用,也不具备用的这个命令行工具,可能需要复杂的,比如说举个例子,就是说人家做对,但是我确实听很多人说这个配置不会玩儿,就是Excel是一个非常优秀的软件,同时里面的工程师非常多,但是他们可能轻视了,为用户提供一个好的使用界面这样一个特点,一个大家会普遍认为呢,可能不好用,类似我们要把这个运维中心要以好的开发体验作为第一个原则。

image.gif第二个就是基础设施五官,刚刚我也反复提到,我们的认知是超负荷的,尤其是在这个云原生时代,我们如果仔细去看一看现在的社区里面的功能,但凡你找到一个大类,比如说安全扫描,比如说会发布,你都能找到两个或以上的类似的项目,他们都各有各的特点,但是,他确实都类似,你可能有的时候呢,觉得选任一个都无所谓,但是有另外一回事呢,就比如说你在某些特定的场景,你发现这个功能还确实更强一些,可能还存在一些切换的需求,但是对于普通的开发的业务的工程师来说,真的不关心用哪一个,如果你把这些概念全都暴露出来,这几个工具虽然提供的服务类似,但是他们使用方法是截然不同的,那这个时候每一个都让这个APP工程师来学,基本上就是认知爆炸,然后同时你在语言上面大家使用云的时候也各有各的这种方法刚刚提到了telephone,可能覆盖的云广一点但是传统的比如说阿里云我们有模板可以非常稳定的想见健壮的去调用云资源这个事也运行了非常多的这个时间了好几好多年了,这种模式其实也是很多用户喜欢的这个不同的配置的使用方式,包括去用控台全都需要去学习,也是一个问题,所以其实大家必然希望有一层这样一个统一的体验层就是你把有一些不需要我关心的先不要让我担心,等我下次需要了解的时候再给我学习的机会,可能这样一个过程就是很矛盾,先是想要关心但是等未来我现在学会了当前这套的时候再给我,这个是比较合理的诉求,所以我们就有一个原则就是要能够提供基础设施无关的统一的体验。

image.gif第三个原则就是我们现在的这个软件的生命周期其实是会有不同的环境,不同的环境分为两方面,一方面左边是你在开发测试,还有生产的这个环境啊,其实大家的这个诉求不一样,比如说你在开发过程中,你可能希望能够直接调试一下,或者说直接登录到这个环境里面去执行命令,同时查看到实时的日志,甚至能够直接创建和销毁的资源,然后可以做一些热加载,但是你到生产环境中,应该没有任何一个靠谱的运维团队会给你这样一个权限,说你能够直接喷到机器上去,对吧,他们肯定会通过一些日志的产品,提供一些可观测性的这种策略给到这个开发工程师去使用,同时也会加入一些特定的,比如说高级安全扫描等等,所以说是同一个软件的生命周期不同,但实际上这里面的实际的环境差别很大,那我们怎么样让这样一个软件的开发可以用相似的体验,能够覆盖不同的环境,就天然需要针对不同的环境去做设计。那另外一方面,就是一个软件,这里是一个软件的不同的开发的生命周期。然后这里是一个软件本身,它不同的组成部分有不同的环境,比如说我有一部分是云服务,有一部分是kubernetes服,这两个平台其实不太一样的,那你在做的时候,比如说有很多朋友来问我,我们和我们的区别是什么呢?这里面其实就很好地回答这个问题。kubernetes的话,在kubernetes里面基本上已经成为了一个事实的打包交付的一个标准呐,但是它只能富含一个·的资源,他很难涵盖这块云的资源,那我们实际的诉求呢,里面很容易就包含云的这样一个资源,然后再加上一个容器的资源,所以我们天然的要面向这个混合的平台,去做一些设计。

image.gif第四个也是我刚刚不断的提到的,就是我们的开发工程师在学会了一定的功能的时候呢,我们希望能够有些变化,同时应该有一些新的技术,能够让我使用,是让我们从过去的这个很多paas,就很多优秀的paas产品,就是被人诟病的一个很大的一个点,就是不太容易扩展,比如说像这种,2010年开始就有很多人提到的这样一个paas平台,它满足了非常多的需求,但是始终有人在说他不够,不够可扩展,它足够用,但是他没办法满足我的这个业务发展的需求,就是当有一天,我发现我的业务复杂了,就不能用了,这张图很好的了,我们有个服务,当你的paas每一个都需要去开发一下才能进入一个新的服务,那么你这个paas团队开发的人力以及你的排期就会成为一个很大的瓶颈,社区不会等你开发完再去产生一个新的技术,那你的旁边的用户就是平台,平台是普通的业务,开发者那么自然就会等不及了,你的业务的发展发现超过了这个平台的发展,但是社区能满足你的需求,那你就得打破这个瓶颈所以其实更多的我们要有可扩展可编程的能力,所以我们的阿里尤其是整个生态啊其实一直在思考这个问题,就是不光是阿里包括微软还有其他的谷歌ns其实公司也都在各自的探索,到了二零一九年的时候,我们和微软一起把对方的实践在一些会议上面分享了一下,发现大家都想到一块儿去了就是所谓的不谋而合吧,大家都觉得应该去构建应用层kbs不干的事情,得有人干这样的事情才能把这个社区的才能让他更好。

image.gif大家一起微软,阿里在2019年10月的时候,联合发布了这样一个open application model,其实这个OAM这个词,现在其实已经在国内相对来说比较流行,我相信大家应该很多人都听过,网上搜的话应该也能搜到,然后就在不到两年的时候,其实咱们国内,信通院也关注到了这一标准,并且联合了不同的厂商,大家一起去将这个这个模型啊,变成了一个行业的标准啊,大家也可以点这个链接呢,去查看,应该在七月份会开放下来,这个正式的这个标准已经标准完全,这个标准也会成为一个行业的标准的驱动,不同的厂商,大家一起去提供同样的模式,能够普惠云的开发者,就是大家写了一套应用的定义,能够在不同的语言上面能够比较好的自由的运行,就像移动和联通,电信这些号码,携号转网就类似于这种能力,但现在还在标准制定的最早期。可能大家的这个想法,在未来的某一些时间,就可以实现,所以这个标准的制定,其实一定程度上,驱动了行业的发展,就是往前走了一个很好的一步,他是一个开始,但是现在可能还没有那么完整,标准里面提出的三个核心的观点,也和咱们提到的一致,第一个,就是关注点分离,应该简化工程师的负担,心理负担。

第二个就是基础设施无关,就是它和不同的云的具体的实现应该不绑定,第三就是能够充分的复用原生态的能力,它可以高度的扩展。那当时我们在发布这样一个模型的时候呢,其实只有一个规范,他没有一套具体的实现的,也就是说你通过这样一个理念,可以自己去开发平台,可以自己造轮子,但是,没有一个能够拿过来直接用的轮子。所以在社区里面,我们就在看到OAM被广泛关注并且受欢迎以后,我们就开始做一个这个官方实现,因为不能这个模型开发出来,只有大厂能够使用。那普通的公司他们可能没有那么大的研发的实力的公司可能也希望能够用这样一套模型,我们就有了去社区里面一起构建一套官方实现的一个想法,快乐的项目诞生了,这个项目其实它很特别他和以往一个公司的开源项目很不一样。

image.gif这个项目从第一天开始就是由很多家不同的公司,大概有几家不同的公司,一起在社区里面一起去构建第一行代码,其实就在社区里面有很多来自阿里微软以及其他的一些公司的工程师,大家在上面的研究,然后同时各自也会运用到公司内部,比如说像我就会把国外的这个技术在阿里云阿里集团里面去推广,去得到一些反馈。然后再去引进到国内的社区里面,所以它的一个很大的不同点就是从第一天开始就诞生于社区,并且在社区里面我们也可以看到他严格遵守我们的四条原则,然后他在社区里面也一直在不断的发展,从一点零的时候呢他完成了一个oam的标准就是我们不用关心底下的实现,只要有一个统一的模型就可以让一个容器的应用或者云的应用起来,然后到了一点一的时候就一点零发布没多久我们就捐赠给cf,因为它本身其实是一个开源社区里面转来的项目所以他捐赠流程的没有疑问,另一方面他也是全球首个交互应用管理的项目,我们捐赠的过程中他也在cf的位置也很特殊,所以我们就非常容易的就加入到了这个cf里面去然后到二零一九年的时候呢我们也把这个一点零时候的那个单机的模式,变成了一个面向混合环境多集群的交付的控制平面,也完成了这里面的第三个原则的一个是一个时间然后到了这个第二年也就是上半年,整个底座在一点一的过程中我们打造的非常完善,所以这个版本迭代啊不断的加速,我们简单的基本上是两个月一个迭代,一月份的时候完成了一个可视化的交互,也就是我们有一个ui的控台,可以去使用这样一个底层能力,不再需要去yamou,只要通过鼠标点击就可以操作。然后一点三的时候呢,他加入了一些企业继承和多管理的能力,到了1.4的时候呢,就是两个月,就是在昨天,我们发布了1.4里面完善了多集群的一些权限,包括安全体系,然后从原先的这种粗放式的权限管理到收敛到这个你可以完整的授权给一个使用者,拥有特殊的指定指定的权限,然后同时也是从多次元的控制,到子集群里面完整的权限控制,全链路的衔接的,就是你不可能说有一些越权啊,所以我们生态非常的这个繁荣,整体来说,有500多位贡献者,我也会仔细的这个提。

image.gif

相关文章
|
7月前
|
Kubernetes 监控 Cloud Native
全栈声明式可观测:KubeVela开箱即用且灵活定制的云原生应用洞察
KubeVela 是一个开箱即用的现代化应用交付与管理平台。本文我们将聚焦 KubeVela 的可观测体系,介绍云原生时代的可观测挑战及 KubeVela 的解决方案。
|
5月前
|
存储 监控 Cloud Native
kubevela可观测体系问题之KubeVela云原生时代可观测性挑战的问题如何解决
kubevela可观测体系问题之KubeVela云原生时代可观测性挑战的问题如何解决
|
存储 资源调度 Kubernetes
KubeVela:云原生应用和平台工程之路
KubeVela:云原生应用和平台工程之路
KubeVela:云原生应用和平台工程之路
|
运维 Kubernetes Cloud Native
KubeVela 再升级:交付管理一体化的云原生应用平台
11月3日,2022 杭州 · 云栖大会上,阿里云智能云原生应用平台总经理丁宇宣布:KubeVela 面向四大核心方向能力升级,打造交付管理一体化的云原生应用平台。
433 6
KubeVela 再升级:交付管理一体化的云原生应用平台
|
存储 运维 Prometheus
「开源人说」| 全栈声明式可观测:KubeVela 的云原生应用洞察体系
随着云原生技术的日趋成熟,越来越多的工作负载都迁移到 Kubernetes 之上,包括各类无状态微服务和复杂的有状态应用。为了支撑这些应用所需的各项基础设施,开发者不得不面对大量的底层 API。这就形成了两个挑战,一方面是难以标准化,各种工作负载自身都会形成自己的运维管理平台,带来了企业平台层的分化;另一方面是过于复杂,带来了很高的使用门槛和稳定性风险。
191306 0
「开源人说」| 全栈声明式可观测:KubeVela 的云原生应用洞察体系
|
运维 Kubernetes Cloud Native
应用纳管和灰度发布:谐云基于 KubeVela 的企业级云原生实践
谐云通过类比事务的方式,将渲染过程分为正向和逆向,同时将首次纳管和真正的纳管动作进行了分离,完成了平台升级的同时,给应用的纳管行为留下了一定的可操作空间。
应用纳管和灰度发布:谐云基于 KubeVela 的企业级云原生实践
|
存储 运维 Prometheus
全栈声明式可观测:KubeVela 开箱即用且灵活定制的云原生应用洞察
作者: 晖树,天元KubeVela是一个开箱即用的现代化应用交付与管理平台,它通过统一的应用模型、可编程可扩展的架构,帮助企业构建统一的平台,向上为不同场景的业务团队按需提供差异化、且开箱即用的平台层能力,大大降低了云原生技术的使用门槛。除了核心的云资源交付、应用管理、多集群、工作流等技术,KubeVela 还提供了全栈的声明式可观测能力,帮助业务开发者灵活定制,轻松洞察各类复杂的云原生工作负载。
全栈声明式可观测:KubeVela 开箱即用且灵活定制的云原生应用洞察
|
存储 运维 Prometheus
全栈声明式可观测:KubeVela 开箱即用且灵活定制的云原生应用洞察
全栈声明式可观测:KubeVela 开箱即用且灵活定制的云原生应用洞察
234 0
全栈声明式可观测:KubeVela 开箱即用且灵活定制的云原生应用洞察
|
弹性计算 Kubernetes Cloud Native
云原生应用平台-基于 KubeVela 构建面向混合云环境的微服务治理规范|学习笔记
快速学习云原生应用平台-基于 KubeVela 构建面向混合云环境的微服务治理规范
云原生应用平台-基于 KubeVela 构建面向混合云环境的微服务治理规范|学习笔记
|
存储 Kubernetes Cloud Native
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(四)
快速学习从 KubeVela 谈起:云原生应用交付会怎样发展