DevOps的下一次演变

2021-12-02   出处:devops.com  作/译者:RAVI LACHHMAN/喜安  

疾病大流行改变了过去习以为常的定义,随着社会渐渐的从COVID-19疫情中恢复,人员、流程和技术也逐渐的适应和发展来应对这些挑战。你所在的企业也会因为疫情而进行数字化转型。

临近 2022 年,许多先前被认为是最前沿的东西已变得成熟,DevOps 正处在成熟的风口浪尖上。作者提出五个应该密切关注的 DevOps 演变:

“工程效率”至关重要

工程效率是一个特别宽泛的总称。在基础层面上,工程效率关注于使人(例如工程师)更具生产力。从组织设计到工程师/开发人员实施,有许多学科相互交叉。工程效率对于当今组织来说越来越重要。这次的流行病在资源和人员配置方面对技术部门产生了两大影响。第一,在大流行开始时,资源的可得性不可预测;由于大流行的医疗严重性,“被公交车撞到”的因素在现实生活中不断上演,物理场所被关闭。第二,在经济复苏期间,大辞职开始了,随之而来的是对资源的争夺变得越来越激烈。两者都意味着资源,特别是倾斜资源,是稀缺的。

工程资源部落/行会的Spotify模型是一种很有前途的发展;人们可以经常四处走动,使工程资源不仅能够更快地增加,而且能够增加参与度和保留率。该行业继续朝着典型定制领域的标准化迈进,比如发布流程,我想我们也会看到这种趋势继续发展。

Git 无所不在

软件工程师过去用源代码管理(SCM)作为解决方案。但随着“something-as-code”从网络、存储以及最终的开发管道等扩散开来,操作工程师继承了软件工程师的许多特征。在你的基础架构中使用更短暂的/一次性的基础架构进行迭代已成为常态。给“something-as-code”源码控制的配置做保存和打包会逐渐成为一个专业领域。

源码控制的基础是包管理器—Docker注册中心、Helm图表存储库等—以获得更多可部署工件;将这些工件投入生产是一个过程。Git在整个技术领域无处不在,这导致了GitOps的继续采用。从 Weaveworks 在 2017 年提出了 GitOps,来到五年后的 2022,GitOps 已被许多组织视为可行的典范,并从绿地项目开始推动。

Kubernetes 不再是新概念

2022 年 Kubernetes 将庆祝其 8th 生日(2014-06-07 在 GitHub 上首次提交)。在Kubernetes(2006年)之前八年,VMware还是一家私人公司,几年后vSphere就发布了(还记得2014年在虚拟机上运行工作负载的感觉吗?)。虽然 Kubernetes 生态系统仍在快速发展,但将工作负载置于 Kubernetes 上已不再是一个新概念。由于应用程序的体系架构采用了Kubernetes方法(换句话说,是幂等的和短暂的),因此在Kubernetes上运行合适的工作负载已经成熟。

Kubernetes的设计是高度可插拔的。如果你不喜欢Kubernetes内部的观点或实现,你可以替换该观点。不喜欢Kubernetes处理入口流量的方式?然后从当前可用的众多入口控制器中选择一个。这只是几十个可插拔区域的一个例子。因此,Kubernetes被视为一种动态的、非静态的资源。使用Kubernetes需要反复试验,让集群变得健壮、高性能和可靠是一个持续的过程,需要不断的迭代。

编写者能成为执行者

毫无疑问,在现代软件堆栈中,我们被数据淹没了。对可观测性(度量、跟踪、日志)的持续科学的探索为我们提供了大量的工作。根据这些数据做出决策,甚至是自动化决策,仍然至关重要。随着 SRE 实践的兴起,对于使用、故障,甚至安全相关项目,如何透过数据做出反应或预测,或更进一步的自动化决策,成为现代团队非常重要的课题。

这些决策可以编写成特定平台可以理解的策略,例如云供应商的自动缩放规则,或者类似于Kubernetes生态系统中的开放策略代理。随着如此多的项目向开发团队左移,要找到合适的资源、技能或机构知识来编写这些规则,可能需要几个团队的投入。由于“something-as-code”的兴起,无论这些规则的编写者是软件工程师、DevOps工程师、平台工程师还是介于两者之间的任何人,都需要具备能力来执行。

左移… 但“复杂性”也左移了

古老的格言是,复杂性就像一个算盘:你可以改变复杂性,但它永远不会消失。随着将责任转移到开发团队身上,这也意味着相关的复杂性正在转移到开发团队身上。现代平台工程团队提供基础设施(兼容的Kubernetes集群),在这些集群上运行的任何工作负载都由拥有它的开发团队决定。通常,开发团队会关注特性和功能。管理大量的非功能性需求,甚至是网络等核心基础设施需求可能是一个负担;考虑一下你的组织将如何处理服务网格。

如果你是DevOps或平台工程师,那么让你的内部客户和开发团队获得成功是一个值得努力的伟大目标。关键是传播专业知识。这可以是自动化和教育的形式。DevSecOps运动的一种常见做法是在构建或部署过程中,进行某种扫描步骤来传播内部内容,包括如何执行扫描,如果发现什么东西会发生什么,等等。而 DevOps 或平台团队亦必须基于信息清晰度和平台稳定性,建构良好的开发人员体验,促使内部的采用和成功。

2022年的发展

尽管去年给我们带来了种种挑战、坎坷和教训,但技术仍在不断发展和进步,甚至降低了进入门槛,使其变得更具包容性。专注于提高工程效率和减少劳动将允许更多的参与并降低进入壁垒。

{测试窝原创译文,译者:喜安}


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
220°|2209 人阅读|0 条评论

登录 后发表评论