开发者学堂课程【云原生技术趋势与行业发展解读：从 KubeVela 谈起：云原生应用交付会怎样发展】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1035/detail/15146
从 KubeVela 谈起：云原生应用交付会怎样发展
内容介绍
一、云原生时代的机会与挑战
二、与原生时代的 DevOps 技术
三、云原生与开源：如何高效参与社区
主要从这个开源技术谈起，讲讲云原生应用交付，包括应用管理这一块的话，现在是一个怎样的发展趋势，它会有哪些挑战，然后下一代的应用交付，应用管理，包括技术，它是怎样的？
一、云原生时代的机会与挑战
随着云原生技术不断的发展，我们在这个技术生态里面，也看到了技术的历史在不断的变化，首先我们在2014、15年的时候，看到了容器技术，容器的镜像技术，把整个单体应用的标准化基本上做完了，也就是说今天写了一份单体的代码，一个goal的代码，或者一个Java的代码，单体的你可以随意的交付到任意的，环境中基本是不存在差异的，但是以前十多年前或者七八年前还有很多程序员讲段子，说我在本地写的代码，然后跑到这个生产环境中，突然间不work，那现在的话有了这个容器，尤其是容器镜像，基本上这个段子呢逐渐从我们生活中消失了，就不太会发生这个情况。另外一块呢，其实就是我们这个款的基础不断的发展，目前，我们也看到基本上它已经成为了实施标准，这个是毋庸置疑的。
尤其他不光是在容器管理这个领域里面成为了实施标准，它已经在逐渐成为一个基础设施的一个交互界面。什么叫交互界面呢？就相当于大家使用基础设施，比如你要去使用计算、存储或者一些运维的能力，网络的能力，那么全都会通过communities去使用。在这个过程中呢，其实也会有一些偏扩展性，大家会在我们那些基础上通过写一些自己的扩展，这个在国内的社区里面呢，它会叫crdoperator，比如说你会去写一些crd，去做一些运维的扩展，之前写一个分布式的数据库是非常复杂的，运维起来也不容易，有了crdoperator之后，可以很容易的写一个集群，几乎不怎么需要进行运维的操作，整体是自动化运维的，另外一方面，其他的的非kpi生态，Terraform等等有很多这样的围绕云，围绕技术设施，sars，pass，这些平台提供的基础设施平台及代码的能力，就是我们所说的ic这些能力也在成熟，我们可以看到iphone已经能够覆盖几乎百分之八九十的各种云的API，所以我们可以通过技术设计代码的方式去驱动我们的底座，通过这个整个方式，我们可以看到现在的云计算的能力，我们更容易的使用，我们只需要写几个简单的配置就可以驱动底层的基础设施的代码，不需要再去写各种各样的复杂的台
。
围绕kps，这个是从CNCF Landscape 2022-05中摘取的图片，这个上面有近一千多个项目，我们可以看到这个生态是非常繁荣的，这么繁荣的生态中有大大小小近千个项目，大家基本上不能全部看完，一方面它证明了这个生态已经成为了事实的界面，所以的能力，无论是运行，运维管理或者是ci以及监控，这些方方面面都在往交互界面上集成，可以看到蓝图上的小卡片越来越多。
生态是在不断地发展，但是DevOps工程师的生存现状的有没有改善呢？从目前来看普遍云原生的新概念太多，各种技术也层出不穷，讲师及周围的工程师很多都认为学习这些新概念有点累了，DevOps原来是开发和运维是两种角色，那现在你希望运维的这个过程也往这个开发这边去考虑，也就是说你的开发的过程中也能负责运维，或者开发运维一体化，一个人就可以全搞定。
因为你底下的这个基础设施能力全都很具备了，你今天再也不需要去学习复杂的网络存储的知识，你就可以有一定的能力，把你写的代码马上上线部署起来。这个过程其实就有很多理论，比一个最有名的理论就是所谓的左移的理论，就是说呢，因为我们现在整体的基础设施都已经非常的容易获得了，那么你再开发的过程中呢，可以更加的关注质量，原先你的代码呢，要设计开发，最后测试，是测试完了到部署了你才能去控制你的代码质量，一般情况下开发的测试的也是两拨人，所以可能要到了测试，这个团队就开发，都已经大部分都搞完了，然后才关注质量，这个时候会发现很多bug，然后再返工，这个效率明显很低，那这个理论也很有道理，就是能最高效的解决问题的方式呢？肯定是在你的代码还没写的时候，比如说你在设计计划的过程中，就能知道你的这个代码质量行不行，然后在开发的过程中呢，不断的开发，马上就上线实验，那肯定是最容易控制质量的时候，大家关注指这个左移的意思，大家关注质量的这个时间周期，越来越往这个开发这边去靠拢。这个意味着在这个开发能力非常强的时候，这个效率是非常高，因为这个人在开发的过程中，马上就可以使一行代码，以前传统的时候，这个代码要在一个月、两个月以后才能看到效果，那现在一行代码搞完几行命令三分钟就能看到实际的效果了，所以效率非常高，但是对于可能更多相对普通的开发者来说，可能我只学了怎么写前端，那你就要去掌握这些各种的能力就有点像这张图，也是网上解答，有点像一个瘦弱的勇士去挑战一个相扑选手，这个过程其实是非常痛苦的，因为你需要学的东西确实太多了。那这个不是dev ops工程师不够聪明，就是我们研究下来感觉其实不是这样，不光是我这么认为，就是有一些国外的专家呢，也是以这种思路去理解这个事情，其实是现在的认知负荷有点爆炸。
当我们去制作很简单的事情的时候，比如说我们要回顾一个配置，那我们的认知呢，其实在一个曲线的相对下面一点，但是当我们需要学的东西，比如说要去创建数据库，你要开始去配置这个灰度发布，你要去开始配置流量，你要再去开始配置这个存储的节点，到底是用高效存储还是普通的云盘啦，你要开始关注这个集群的网络，这个时候呢，你的这个认知呢，会不断的往上攀升，你要了解的东西就越来越多，那这个时候自然而然你的这个工作的效率会降低，然后你会觉得很痛苦，然后所以我们认为一个团队，他能够承载的认知负荷，一定是有界限的，那水平高的团队呢，可能认知负荷能够高一点，水平低一点的，可能就相对来说偏中位线以下的一些，那合理的这个方式，不是说把所有的这边右边的东西一股脑的就全都抛给这个开发团队这边来了，他应该是有一个界限的，就是我们在开发团队这个认知的范围内能够理解的东西呢，应该让这个开发团队去操作，并且越灵活越好，因为你藏的东西越多，那他就越不自由，那只能受制于右边的这个平台的团队，或者所谓的运维团队来操作，但是当我的这个认知超过了，我就不应该关心太多，因为开发的这个心智负担越低越容易把事情做好，同时越稳定越安全，否则你对于一个不了解的东西，可以凭勇气去点击一下，但是如果出了事，这个背后到底会发生什么就一无所知，很容易出现很大的风险。所以认知负荷控制在越小的合理的区间越好，那我们也不能说这个线是不会动的，因为随着我们的这个能力的习得，比如说开发团队已经了解了，这个配置怎么回滚了，几乎所有的人都知道了，他已经成为了常识了，那其实这里面呢，就不需要聊太多，因为大家已经习以为常，比如说你一个操作操作了五年，那你到第六年的时候，你都已经成为了你的这个肌肉记忆了，可能你就不太需要你再增加一个新的技能，你觉得新鲜感，因为你一个工程师工作了三年，工作了五年，只会点击一下这个上线发布这个按钮，新的知识一个都不会，一方面就会觉得这个工作很无聊，另外一方面，他也会焦虑，就是你没有掌握新技能跟不上潮流，这跳槽就没机会，也也学不到新的东西，也会焦虑，所以我们必然要能够让这边的开发者时不时也要学点新东西，就是你不能固定一个东西，业务也会发展，对需求也会变化，场景也会变化。所以开发团队能够接受的负荷，他一定会缓慢地往上走的，你必须要能够灵活地提供这样一个拓展的这个能力呢，给到开发者。所以我们可以来思考一下，我们既不能太复杂，又不能太容易，那我们就要从开发者最核心的一个诉求开始出发，然后看看到底在这个云原生时代，我们应该怎样去把这个平台做起来，或者说开发者，我们普通的开发者，到底应该用一个怎样的平台，Deoveps的这个流程到底应该是一个怎样的。
其实如果我们把当前一个应用，一个软件的生命周期去做一层抽象的话，其实我们就发现，我们整体来说一共就分三个阶段，这三个阶段分别是，首先你要写代码，你要把这个代码，对应的把它调用的API要了解，然后同时，你要开发，你要测试，你要很容易的得到这个测试环境，同时，你的开发测试环境，最好和生产环境相应的一致，比如说你可能有依赖一些第三方的服务，依赖一些公司同事，其他团队写的一些微服务，然后同时，你还会依赖一些存储的API，或者说这个中间件的API，那你要能够非常容易的发现和使用这些API，所以这个，就是在开发过程中，你要构建你的这个软件，那第二个阶段，就是这个软件已经开发好了，你自己觉得测试好了，那你就要能够去把这个软件，发布到你的生产环境，这个发布的过程，其实是一个相对比较讲究的过程，因为现在大家很多都是互联网业务，那每时每刻都有用户，比如说我们今天直播，那不可能直播的过程中，我发布一个应用直播，用户全都掉线了，这个是不能接受的，所以基本上都会要求能够灰度的发布，就是我在上线生产的过程中呢，不会去影响我已有的用户，这个过程应该是安全的过程，然后如果我发现我发布的这个新的这个程序，这个软件有bug，那么也要能够快速的回归，所以在交付的过程中，我们核心诉求就是可以灰度的发布，可以回本。第三个阶段，自然就是我什么都没做的时候，这个软件最好能够一直稳定运行，那基本上正常的程序员也不可能期望这个软件没有bug，大家都相信，这个一定是有bug的，这个区别就在于它发生的概率到底是高还是低，那你的这个软件一旦出现bug最希望的是他能够一定程度让自己恢复。现在其实我们这一套基础设施，云原生已经把这套理论玩得很好，他推崇的是不可变基础设施，如果你的这个软件出了一些问题，比如说挂了，他会帮你自动的重启，面向中泰去恢复，你的这个网络出现问题了，等会帮你自动来做一些迁移，比如说某一台机器的挂了，他会帮你在另外一个地方再重新调入其中一台机器，所以它的自愈能力呢，在开发生产的已经做得很好，还有一点就是你写了一些大规模的bug，或者说相对来说非常异常的一些行为，他可能已经没办法通过简单的自愈能力恢复这个。
那这个时候，可观测就需要能够让你快速的捕获到这些异常，并且给你报警。我在运行阶段其实最核心的诉求呢，在原生的这套基础设施的基础之上，需要有一个比较好的观测能力，才能让我们快速地发现问题。甚至在事后呢，第一个发现问题。所以我们发现其实我们诉求很简单，就是构建，交付和运行，但是为什么这么多问题的发生已经这么多年了，却一直迟迟看不到一个比较好的这个结论，或者说所谓的KBS官方怎么没有提供这样一个能力，这个答案，其实是不会去提供这样的能力的，因为他们在官网的第一页文档就写了我们这次不是，我们也摘抄了一段话给大家。
就是恐惧呢，他故意呢，不做这样一个面向用户的营销和官员，他认为他应该是一个大家公共能够使用的底座，他不想针对某一些，可能跟不同团队，不同公司打交道，更多的偏向于基础设施，然后，其实社区有很多布道师，谷歌等，谷歌首席布道师他其实自己也说了，这句话是一个名言，大家都会拿这句话去说，就是it is a plat form for view in platform，是用于构建平台的平台，他不是说你拿过去用就好了，他是你构建平台的开始，你应该拿过去，自己去搭一套平台给用户用。他是一个很好的巨人，你应该站在他的肩膀上呢，继续去操作，所以可以看到，基本上你也可以放弃官方去提供这样的能力，那这个时候呢，要思考到底这个时候divorce这一块到底该怎么去发展呢？
