从 DevOps 到平台工程:软件开发的新范式

devops,平台,工程,软件开发,范式 · 浏览次数 : 370

小编点评

**DevOps 反对论点** **1. DevOps 的模糊性** * DevOps 的定义过于模糊,缺乏一个明确的标准。 * DevOps 对不同企业和团队来说意味着不同的东西。 * 缺乏共识,一些言论表示 DevOps 只是一个被供应商和行业顾问过度使用的流行词。 **2. DevOps 实施成本高** * DevOps 需要对企业的文化、组织架构和技术进行大幅度的改变。 * 由于 DevOps 实施后的实际效果尚未确定,企业可能难以确定是否值得投入。 * 部分企业中的 IT 主管或领导并不愿意在此花费过多。 **3. DevOps 的复杂性** * DevOps 通常涉及多项技术挑战和较高的复杂性。 * 开发人员必须处理复杂且多样的基础设施、安全、合规和运维等问题。 * 复杂性增加可能导致开发人员无法将核心能力价值最大化利用。 **4. DevOps 的不可持续性** * DevOps 实施是一个持续的工程,需要不断更新和维护。 * 开发人员需要持续学习新技术和最佳实践。 * 缺乏持续性可能会导致 DevOps 的失效。 **5. DevOps 的替代方案** * 平台工程是一种可以帮助企业应对 DevOps 的演变阶段的技术。 * 平台工程可以赋能开发人员,并提供一个可持续的平台。 * 平台工程可以帮助企业实现更快更好的软件交付。

正文

DevOps 是一种将开发和运营结合起来的方法,在应用规划、开发、交付和运营方面将人员、流程和技术结合起来。DevOps 使以前孤立的角色(如开发、IT运营、质量工程和安全)之间进行协调和合作。一直以来,DevOps 的采用都是以帮助企业更快地向客户提供价值,更好地适应市场和竞争,并保持系统的稳定性和可靠性为目标。
 

然而,近两年关于“DevOps 已死”的讨论越来越多。该观点持有者认为 DevOps 模糊性,实施起来的复杂性及高成本等问题,未能达到帮助企业实现其加快交付、提高质量和降低成本的目标。
 

在这篇文章中,我们将理性分析一些反对 DevOps 的常见论点,并一同探讨在当下 DevOps 实施时所面临的挑战,以及 DevOps 未来演变与平台工程的关联。
 

反对 DevOps 的三大观点

DevOps 的定义过于模糊

关于 DevOps 的批评之一是它过于模糊,缺乏一个明确的定义。DevOps 对不同企业和团队来说意味着不同的东西,而且对 DevOps 的实际内容也没有达成共识。甚至有言论表示 DevOps 只是一个被供应商和行业顾问过度使用的流行词。
 

DevOps 实际上并不是一套僵硬的框架或规则,而更是一种文化和思维方式,能够适应不同的环境和目标。DevOps 并没有规定团队应该如何工作,而是提供了可以帮助团队更好地合作的原则和实践;也没有规定团队应该使用什么工具,而是鼓励团队使用最适合他们需要的工具。因此 DevOps 的模糊性我们可以视为它的灵活性。DevOps 允许团队根据他们的具体挑战和机会来定制他们的方法,还允许团队进行试验并从经验中学习。
 

DevOps 给企业造成成本负担

反对 DevOps 的另一主要观点就是,DevOps 的实施和维护成本过高。由于 DevOps 需要对企业的文化、组织架构和技术进行大幅度的改变,同时,还需要企业在时间、成本以及基础设施方面进行大量投资。因此有部分企业中的 IT 主管或领导并不愿意在此花费过多,因为他们无法保证 DevOps 实施后的实际效果。
 

不可否认,企业实施 DevOps 的确是个不小的工程。但客观来说,DevOps 并不一定是一个全有或全无的主张。企业可以逐步和有选择地采用 DevOps,根据自身需求和商业目标来选择合适的工具和实施方式,企业中现有的资源和基础设施也可以被利用起来。这样企业可以将采用 DevOps 的前期成本和风险降到最低。
 

关于实施效果,DevOps 并不是一套即时的解决方案,需要从长期利益来看。DevOps 可以帮助企业减少交付过程中的浪费、错误、延迟和失败,同时提高软件交付的质量、效率、团队间的协作以及客户满意度。从长远来看,这些成果可以转化为更低的成本、更高的收入和更好的竞争优势。
 

DevOps 过于复杂

第三个反对 DevOps 的声音来自于对其复杂程度的质疑,认为 DevOps 难以实施和管理。DevOps 通常涉及多项技术挑战和较高的复杂性,因此导致开发团队和运营团队难以上手。同时还涉及跨多个团队的大量协调和沟通,这在大型或分布式组织中可能是个极大的挑战。
 

实际上 DevOps 是为了简化和精简软件开发生命周期,而不是使其复杂化。DevOps 依赖自动化、标准化和集成,以减少人工任务、错误和依赖性。此外,DevOps 并不是一个适用于所有情况的万能解决方案。企业需要根据他们的具体环境和要求来定制 DevOps 方法,并利用各种工具和技术来促进 DevOps 的实施和管理。例如,使用版本控制来跟踪和记录变化;或使用告警管理来统一和优先处理紧急状况。
 

DevOps 实际存在的问题

DevOps 自 2007 年随着企业规模、行业以及现有的 IT 环境的变化,针对 DevOps 的反对声音也并非空穴来风,DevOps 在概念上、流程和技术等方的确面临着巨大的挑战。
 

首先许多企业对 DevOps 的概念存在误解,未能采用 DevOps 的基本原则和文化,导致实施时存在偏差,即仅仅雇佣一个“DevOps 工程师”或使用一些 DevOps 友好的工具。这就导致了混乱、孤岛和低效率等问题。因为 DevOps 并不是一个角色或一个工具,而是一种思维方式和一种实践,需要企业变革和确保一致性。
 

DevOps 的核心理念是“you build it, you run it”,这给开发人员增加了过多的压力和认知负担,开发人员不得不处理复杂且多样的基础设施、安全、合规和运维等问题,开发人员通常不擅长或缺乏处理这些任务的技能和工具,从而需要耗费大量时间和精力。而过多的精力花费在非开发任务上,导致开发人员无法将核心能力价值最大化利用。
 

此外,随着分布式系统的广泛应用,其复杂性越来越高,DevOps 变得更加难以实施和管理(当然问题的根本来自于现代软件开发的复杂性增加而非 DevOps 本身)。企业需要对其基础设施和环境有更多的控制和可见性,以及更多的敏捷性和速度来满足业务需求。DevOps 也难以应对云原生技术(如容器、Kubernetes、微服务和无服务器)的多样性和波动性。
 

平台工程的崛起

为了解决上述问题,一些企业正在尝试将 DevOps 演变到下一阶段,通过创建可重用、自助式平台的实践,使开发人员能够以最小的摩擦构建、部署和运行其应用程序,这就是平台工程逐渐崛起的契机。
 

平台工程相比 DevOps 有以下几个优势:
 

  • 赋能开发人员:平台工程为开发人员提供了一个“黄金路径”,为他们的应用程序提供最佳的工具、实践和安全措施。开发人员可以自助获取他们需要的资源,而不用担心底层的细节或依赖关系。平台工程还通过降低复杂性、提高生产力、增强质量和加速反馈循环,改善了开发人员的体验。

  • 启用平台工程团队:平台工程拥有专门的平台工程师团队,负责构建、维护和改进支持开发人员的平台,平台工程师充当促进者和协调者。同时,平台工程师可以利用云原生技术(如容器、Kubernetes、微服务和无服务器)创建可扩展、弹性、可移植和成本效益良好的平台。

  • 利用平台编排:平台工程使用平台编排工具,自动化跨不同环境的平台的配置、部署和管理。平台编排工具还提供对平台及其使用情况的可见性、监控和治理。平台编排工具帮助平台工程师为开发人员提供一致、可靠和安全的平台。

  • 改善业务成果:平台工程通过实现更快更好的软件交付,帮助组织实现其业务目标。平台工程能够培养开发人员和平台工程师之间的协作、创新和学习文化,并帮助组织以可靠、高成本效益和安全的方式进行扩展。
     

结论

DevOps 并没有死,而是在革新和进化,平台工程则是 DevOps 的下一个演变阶段,相较于 DevOps,其优势是以可持续的方式赋能和助力开发人员。平台工程能够帮助企业组织应对云原生环境的复杂性和增长,同时实现更快更好的软件交付。

与从 DevOps 到平台工程:软件开发的新范式相似的内容:

从 DevOps 到平台工程:软件开发的新范式

DevOps 是一种将开发和运营结合起来的方法,在应用规划、开发、交付和运营方面将人员、流程和技术结合起来。DevOps 使以前孤立的角色(如开发、IT运营、质量工程和安全)之间进行协调和合作。一直以来,DevOps 的采用都是以帮助企业更快地向客户提供价值,更好地适应市场和竞争,并保持系统的稳定性

研发效能DevOps推荐书单

专注 300 页之内的经典书籍推荐 研发效能涉及的知识很多,从大的方向去划分包括制度、组织、平台、运营等;单从软件研发的角度去看也包括很多,包括最底层的软工认知、实践,到团队管理和组织、敏捷研发,项目管理、源码管理、发布管理、可观测性,到产品的运营和反馈。 现在很多公司已经组建了或者正在组建研发效能

DevOps 必备的 Kubernetes 安全清单

Kubernetes 是当今许多公司采用的容器编排平台,它的实施需要对其生态系统有一定的了解,以便部署一个准备好用于生产的集群。然而从原则上来说,Kubernetes 并不是一个安全的平台,因为它缺乏处理大多数与安全相关任务的本地工具。 因此,Kubernetes 的实施工作原理或工具至关重要,这个

NodeJS 实战系列:DevOps 尚未解决的问题

本文将通过展示 NodeJS 应用里环境变量的提取过程,来一窥 DevOps 技术是如何应用在现在云平台上的运维工作中的。同时我也想让大家在这里看到 DevOps 的另外一面,即它并非全能,从本地开发到持续部署再到实际运行,有一些运维鸿沟依然还未被填平。“人工操作”依然是工作中的最大风险。

一文梳理2048小游戏从开发到上云全流程

摘要:本文主要以Cocos2d Web项目2048小游戏的开发上云为例,介绍DevOps开发实践的全流程 前言 本文主要以Cocos2d Web项目2048小游戏的开发上云为例,介绍DevOps开发实践的全流程,主要涉及开发工具为华为云软件开发平台DevCloud和CocosCreator。按照整体

我们从 CircleCI 安全事件获得的3个经验教训

CircleCI 作为业内最受欢迎的 CI/CD 平台提供商之一,有超过20万个 DevOps 团队使用其平台。该公司在今年1月在其官网报告了一起安全事件引起客户恐慌。在此事件中,有身份不明的恶意攻击者入侵了一名员工的笔记本电脑,利用恶意软件窃取了员工的 2FA 支持的单点登陆会话 cookie,使

从DevOps实践落地的角度谈谈“流程”和“规范"的反模式

最近在经历的一些事情,让我突发灵感,觉得要写点关于DevOps体系建设过程中的“流程规范”,记录下来。 如何解读"流程规范" 谈到DevOps落地,无一例外都会提“流程规范“,我想没有人会反对,甚至会”不放在眼里“,因为概念本身没有什么晦涩难懂。可是一到落地,好像就是另外一番场景,“一地鸡毛”,“形

DevOps|从腾讯TEG CDC解散聊技术中台价值和建设

近日一则腾讯TEG CDC整个部门解散的消息在很多群里炸了锅,有的唱衰互联网行业,有的唉声叹气,还有的甩锅到 AGI 的发展。总体上来说,这个事情的确已经发生了,我想从组织架构和整体效能这两方面来分析下这次组织变化。 腾讯TEG CDC解散 6月28日,网传腾讯TEG CDC整体解散,人员涉及设计师

DevOps全面综述:从概念到实践

这篇文章详尽介绍了DevOps的背景、核心实践、工具和技术,探讨了团队协作、文化建设及组织变革,旨在帮助企业高效实现持续交付和创新。 关注作者,分享互联网架构、云服务技术的全维度知识。作者拥有10+年互联网服务架构、AI产品研发经验、团队管理经验,同济本复旦硕博,复旦机器人智能实验室成员,阿里云认证

DevOps|乱谈开源社区、开源项目与企业内部开源

之前的一篇文章《从特拉斯辞职风波到研发效能中的荒唐事》中关于企业内源的内容在研发效能群内引起了大家的热烈讨论。有的小伙伴不同意,有的小伙伴非常不同意,我觉得这都是非常正常的反馈,话不说不透,理不辩不明,我还是特别希望能和大家一起把这个问题弄明白。这篇文章就是那篇文章的后续,本文主要讨论开源社区、开源