DevOps的出现带来的变化

概念

Dev:开发,和code打交道的

Ops:运维,部署底层架构

DevOps是一种思想论,结合了人-流程-技术,为客户提供了可持续增长的业务价值。

DevOps出现前后

没有DevOps之前

作为开发:职责是更多的代码,更多的feature

作为运维:职责是系统更加稳定,更为可靠

可以发现,开发和运维的KPI在底层是冲突的,更多的feature势必带来更多的不确定性,将给系统的可靠性带来挑战。

另外,传统的应用从需求提出到部署上线整个周期可能很长,短则数月长则至年。当PM提出新的需求时往往需求的反馈路径较长,无法得到开发的及时回应,且变更带来的难度也较大。从应用角度来讲,传统应用往往采用单体方式(巨石应用),修改某个部分一般也需要连带修改其他依赖它或者被它依赖的模块,这也带来了麻烦。

有了DevOps之后

从应用层面:巨石架构的单体应用按功能职责划分为微服务,单个服务的生命周期与其他服务解耦,这给整体应用的部分模块持续迭代更新带来了便利。

从软件生命周期层面:应用从需求提出到编程再到部署、测试上线、监控最后又重回需求,整体呈现一条闭合圆环,且圆环走完一圈的时间一般较短。同时,圆环末端监控环节也为新需求的提出提供了依据。这样,应用在一圈一圈的循环中持续构建和优化。

从部署上讲:传统应用一般部署在实体服务器上,或者VM等。而符合DevOps的应用一般部署在云上。

开发方式上的变化

waterfall开发方式

这种开发方式属于传统型应用的开发流程(没有使用DevOps),一个软件从客户提需求开始,到开发测试最后到交付是一把梭的,可能最后交付的时候和一开始提供的需求有偏差。且如果在中途客户对应用的需求做出了变更,也会带来很多的麻烦。这里我对瀑布的理解就是应用所有的API像瀑布一样在最终交付的时候涌现。

敏捷开发

敏捷开发其实就是应用了DevOps后的开发方式。之前提到了DevOps可以理解为一个短周期的需求实现圆环(包括从需求到最终监控再到需求的圆环)。那么在应用的开发过程中我们将不再依靠瀑布式的最终交付形式了,而是将一个应用拆分为众多需求,并且作为需求提出方将给需求按重要性赋予权重,而每个需求都对应一个"圆环"。开发在每一个需求圆环的实现过程中与客户进行沟通和对齐,使得最终交付和客户的意愿相同。圆环在每一次循环过程中都在为客户提供更大的、持续增长的业务价值,这也是DevOps精神的体现。

相关推荐
运维&陈同学1 小时前
【zookeeper01】消息队列与微服务之zookeeper工作原理
运维·分布式·微服务·zookeeper·云原生·架构·消息队列
是阿建吖!1 小时前
【Linux】进程状态
linux·运维
明明跟你说过2 小时前
Linux中的【tcpdump】:深入介绍与实战使用
linux·运维·测试工具·tcpdump
Mr_Xuhhh3 小时前
重生之我在学环境变量
linux·运维·服务器·前端·chrome·算法
朝九晚五ฺ10 小时前
【Linux探索学习】第十四弹——进程优先级:深入理解操作系统中的进程优先级
linux·运维·学习
Kkooe11 小时前
GitLab|数据迁移
运维·服务器·git
久醉不在酒12 小时前
MySQL数据库运维及集群搭建
运维·数据库·mysql
虚拟网络工程师13 小时前
【网络系统管理】Centos7——配置主从mariadb服务器案例(下半部分)
运维·服务器·网络·数据库·mariadb
BLEACH-heiqiyihu13 小时前
RedHat7—Linux中kickstart自动安装脚本制作
linux·运维·服务器
MXsoft61815 小时前
华为服务器(iBMC)硬件监控指标解读
大数据·运维·数据库