共计 1825 个字符,预计需要花费 5 分钟才能阅读完成。
本文首先会和大家分享当前整个应用生命周期的演变历程,然后讲解云计算模式下 DevOps 建设包含的过程、流程规范和标准,最后讲解云原生时代到来会带来哪些改变,以及标准化的建设会有哪些改变和突破。
应用的演变历程
企业数字化转型过程和云的迭代发展是相互作用的。在 2007 年之前主要用物理机来作为我们当前应用的载体。而在 2007 年,KVM 诞生,它能让底层操作系统和一些虚拟的网络设备做一些虚拟化的输出。2007 年 – 2010 年是虚拟化发展较好的周期,VMware 和 openstack 是当时的代表生态。到了 2013 年 Docker 开服,云计算迎来了蓬勃发展的周期。2014 年,企业的部分业务开始逐步迁移云上。2017 年后到今天为止,在云原生的模式下,开发人员或者整个 it 部门更聚焦在业务的发展上,所有我们不关心的部分可以全部由云来管理。云开发不必关心开发在哪里,云服务不关心调用到哪里,而云资源方面也不用关心运行到了哪里。这就是从基础设施上云到业务上云,再到当前的全栈云,这样的一条全企业数字化转型之路。
在物理机阶段,使用的是单体架构,这样的架构系统封闭、无法复用,且高度耦合,内部交互复杂。而在第二阶段,采用了面向服务的 SOA 架构,这种架构通常需要 ESB 进行系统集成,进行应用模块解耦,需要统一部署。但是这种架构通常需要较大规模的团队,且可能存在职责割裂。第三阶段是当前使用的比较多的微服务架构,它能充分利用 DevOps,完全解耦能充分利用云化资源自动弹性伸缩等特性,支持高可用,能升级、扩容但不中断业务。
这张图片能较好的展示应用的生命周期管理,以应用为中心,在应用之上是基础资源管理层面,这个层面可以管理应用对应的资产、环境、资源、流水线、部署和监控,这是以基础资源为核心思想下 DevOps 的建设方向。随着越来越云化和微服务化,我们关注的视角从基础资源逐步转成服务思想。
云计算模式下的 DevOps
在物理机时代,随着业务的发展,可能会出现基础设施增长,软件复杂度提升,流量冲击和更新频率变高这些问题。基础设施增长和软件复杂程度提升会给运维带来压力,流量冲击要求运维的测试要有多样的变化,更高的更新频率要求研发人员的快速反馈以及更灵活的需求变更。
在这样的情况下,DevOps 建设迫在眉睫,企业需要提升应用交付的效率和质量,需要越来越多样化的应用部署方式。DevOps 建设要首先要做的是敏捷的建设,因此需要更灵活的需求管理工具,在整个应用交付阶段需要自动化构建和环境快速管理。然后在测试的阶段,我们需要做自动化测试,才能在流程中管控好质量,另外还需要有一个统一的制品管理。从软件开发到应用交付之间,需要有一套统一的制品库将所有的制品进行统一纳管,基于统一的制品可以进行智能化的验收测试。在这整个阶段,核心准则是版本控制一切,内建质量、自动化,过程度量。
这个图片是端到端的 DevOps 能力图谱,建设的重点在图谱下方的持续交付工具链。我们需要采取统一的代码管理工具,帮助我们自动化的提升代码的质量。在安全方面,我们也会运用安全扫描工具集成到流程中,让它进行自动编译。另外,在持续部署阶段,要做好数据库的发布,对不同版本的接口做好管理,并结合一些好的自动化的工具做自动化测试。这些功能点需要一个交付部署流水线串连起来。
我们可以看到,在端到端的能力中会有很多步骤,也需要非常多的工具去执行,如何将这些工具进行很好的串连呢?在企业生产过程中,核心目标有三项:效率、质量和成本,因此可以沿用制造业的流水线来帮助我们快速的生产软件。流水线中我们需要关注 4 项指标:发布频率、变更时长、服务恢复时长和变更失败率。
云原生带来的改变
云原生是一个复杂的东西,它包含开发过程、应用依赖、编排管理、流程管理、数据分析以及非常多的组件。在云计算的模式下,我们可以做到快速交付应用、成果快速发布,但是我们交付的产品是否能给业务带来增长,满足客户的需要呢?这就涉及到如何将应用交付转变为价值交付。通过可靠、可重复的流水线,快速进行软件生产,提升应用效率和软件交付效率,这就是应用交付。而价值交付是指能够快速地响应市场变化,在客户需求不确定的情况下,生产出客户满意的软件。
如何实现价值交付?要基于可靠可重复的流水线,简历自动化的应用交付体系。将敏捷过程全面融入到 DevOps 体系中。架构全面微服务转型,基础设施云化,让开发专注于业务开发。将运营纳入到 DevOps 范畴,实现数字化运营。
点击观看课程完整视频。