开发者学堂课程【ALPD 云架构师系列：云原生 DevOps 36计-阿里云云效出品：云原生时代软件交付的挑战和机遇】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/772/detail/13494
云原生时代软件交付的机遇和挑战
内容介绍：
一、挑战一：业务发展的诉求
二、挑战二：软件交付形态的变化
三、机遇：技术的发展推动应用架构和部署架构的演进
四、机遇：云基础设施和云原生技术的兴起
五、传统软件工程实践的和云研发工程实践的区别
一，挑战一：业务发展的诉求
如上图，这张图代表了什么意思呢？
直播行业刚兴起的时候，还有共享自行车刚出现的时候，整个业务发现这一领域，于是所有人都加入其中，但是做的好坏它的结果是完全不同的。
其实就是需要能够快速响应，但是如果技术跟不上，那制作的东西就会拖后腿。
我们都知道这些行业的窗口期很短，比如直播，共享单车的窗口期，可能过了几个月时间，你就没有机会了，所以曾经有这么多的直播 app，现在也只剩下少数还在运营。
软件交付能力：
DevOps 年度报告2018年年度报告给软件交付提出了度量的一个指标或者说相应的一些体系，通过这些数据可以帮助我们理解什么样叫比较好的一个效能的交付能力。
软件交付能力的指标：
部署频率：指的是应用和服务，也就是从代码到部署到生产的频率。
变更前置时间：就是说从代码提交到能在生产环境运行起来的时间。
服务恢复时间：服务中断之后，到下一次服务恢复到能够继续服务的时间。
变更失败率：作为一次代码的一个变化，要最后能够发布上线的时候有多少次是成功的，多少次是失败的。
通过上面的这个表格，可以看到精英基本上它部署频率是按需。变更时长也就是从电脑提交到最后部署生产基本上小于一个小时。服务恢复时长基本上再下一个小时。变更失败率是在百分之零到15%之间，那低效和精英之间比较，通过对比可以看出自己是属于精英的，是低效、高效，还是中等的。
管理成本：对于一些团队，比如是一些正处于快速创业发展期的，团队的人越来越多，管理成本也越来越高了，这个时候当完成一个需求时，就会发生原本并不需要去协作，但是现在要很多人来一起去完成的现象。所以随着人数越来越多，速度就会越来越慢。
例如：有一个创业的团队，最开始只有八个人的时候，但是每个礼拜都可以发出一个版本，而后来他们有80个人的时候，半年一个版本发不出去。这其实就是人越来越多管理成本越来越大协作的复杂度越来越高。
技术债务：因为业务一直在跑。因为在互联网创业里头有一种方式,就是不论如何，先跑起来，但是可能往往过了一年，或者两年之后，会发现你跑不动了。一开始你要去做的很好的时候，有的时候业务不会给你太多的时间来去做相应的一些事情，所以说技术债务越来越高之后，等再去做相应的一些事情，你会发现就要连本带息要一起还了。
新技术引入困难：当有一些比较好的技术，或者比较好的一些实践时，因为人员的成本的问题，不可能找到所有方面都是优秀的人，比如一些测试，同学们很难去做，还有引入一些比如说测试自动化的一些工具或者手段。而且有的一些技术是有门槛的。比如说安全领域，云原生领域，对于一些小公司，想要自己开发的时候，怎么样的运营，，体系要怎样建立起来是非常困难的。因为没有足够多的人员与精力。所以业务要求越来越快，技术也越来越多，但是要变成精英是很困难的，这就是第一个挑战。
二，挑战二：软件交付形态的变化
上图左边是之前软件的一个交付形态，中间有三个里程碑。里程碑一什么时候、里程碑二什么时候、交付什么时候。里程碑一里程碑二的时候其实看不到什么，能说出做了多少模块，但是看不到整个系统，可能过了一年、两年，我交付给你一个产品，但这个时候这个产品质量如何就只能听天由命了。例：今天给了一个项目，这个项目要求两百多人用时两年半完成，但是做到一年半的时候，在做第一次模块间集成的时候发现中间的模块跟另外一个模块集成不起来，结果就是接下来的半年都在解决这个问题，直到最后都没解决了，这样的结果是很痛苦的。
但是现在的交付形态不同了，就是说我希望你每天都能交付给我一些东西，也就是这个服务是一直在线的，不是你给了我一个里程碑然后说三个月后给我一个完整的东西，而是持续的要有一个服务，这个服务是增量的，发生的，而不是一个合同制。所以这个变化是非常大的。
做电信设备的交流很难，因为开发环境和生产环境的网络是不通的，也就是要做一次发布和实施非常难，成本也特别高。所以说这种软件形态交互的一个发生了的一个变化对研发模式也提出了更高的要求，那么就不可能像原来一样有很长的 plan， 然后等到最后、半年后，或者两年后做一个集成的方法去做交付实施，所以他要求持续的每个迭代都有东西往外生产。
当软件可以做到持续发布，持续升级了之后，可用性也提出了更高的要求。就是说你提供的服务是需要非常高的可用性的。另外就是质量对持续交互是非常重要的，因为每次发布上线很容易，但是如果说质量出了问题就很容易导致很多的故障，甚至会要公司出面来去各种公关。所以说在这个过程中，软件交付的这种形态和交付的这种方式，也在给我们提出了多的要求，或者说需要通过一些其他的一些手段来去做，这就是我们看到的两大挑战。
三，机遇：技术的发展推动应用架构和部署架构的演进
上面的图中，先看蓝色的这个编注，从资源的角度来说，从云托管到后面云优化，再到现在的云原生我们会发现在资源的角度，会发生一些变化的一些迁移，从应用架构看，从以前的单体应用，到现在的 Serverless，其实它也是有一个架构的变化，从原来开的越来越近的，慢慢的分得越来越开，而且拆的越来越小。从部署价格的角度也可以看出，从原来的物理机到慢慢现在到面向 Bass/Fass，在这里画了一个简单的象限来说明，应用架构和部署价格的演进对软件的交付模式带来了非常大的一些变化，而且整个交付会变得更灵活，更解耦。能让工程师更多关注在业务逻辑上，需要关注下面的东西越来越少，而且其实这个过程发生很快，从物理机到现在Fass，可能只十来年的时间。给人一种感觉就是越来越快，是处在一个变化非常快的时代。
四，机遇：云基础设施和云原生技术的兴起
云基础测试的抽样层次越来越高了，在一二或者一三年的时候，当时对阿里云的印象就是一个虚拟机，那时考虑 IDC 就是买或者租一台机器放在一个机房里面，然后给他托房，这在那时是很常见的情况，当时对云基础设施的理解就是基础设施 infrastructure 。但是随着技术的变化，随着容器的兴起。有了容器平台，现在的 ACK 跟 K8S 平台都是基于这个做，但是这个还不够，把中间建的能力也再下沉下去很多便又有了一个 PaaS ，这样的话很多的能力就在 PaaS 层体现了，不需要去关心说消息队列、存储、监控，很多东西也不用关心了。
第二点，Docker 提出之后，到 K8S 跟现在的 CNCF，你会发现，目前K8S已经是一个事实上的标准，这个标准感觉是一个牢不可破的。就像云原生，现在大家不会讨论要不要去做它，因为它已经是个趋势，大家都认为要做，那么只有怎么做的问题了。同时随着这个两个的演进，服务被越拆越小了，就是说现在基本上都在谈微服务，但微服务会带来很多之前没有的问题，其中一个比较典型的问题就是服务治理。就是服务的数量太多，那么这个服务该怎么治理呢？服务发现怎么做？负载均衡，服务监控、容量调度，服务之间的测试、我的链条，各种问题等等......大家对服务治理的诉求就变得越来越大，而且服务的数量越多，它的复杂性就越高。比如说你的一个服务的实用性是99.9%，那十个服务就99.9%的十次方，实用性就会降。同时它本身的复杂性也会越来越高，而且对我们来讲会带来很大的一个成本。所以在整体上来说，整个研发里头，有两个挑战而且目前来说还有一个机遇，就是这技术的演进带来的一些机遇.
五，传统软件工程实践的和云研发工程实践的区别
传统的业务响应方式、软件架构、测试方法、交互形态和交付周期、部署方式和运维方式，都和云研发时代都是有非常大的不同。传统是软件售卖的方式，现在传统企业还是按这种方式。但是目前来说就是云研发里能做到的连续升级的这种并不一定必须是在互联网企业才能做，传统企业也可以做这个事情。
