生成式AI领域的最新成果都在这里!抢 QCon 展区门票 了解详情
写点什么

DevOps 已死,平台工程才是未来

  • 2022-10-11
    北京
  • 本文字数:4198 字

    阅读完需:约 14 分钟

DevOps 已死,平台工程才是未来

开发者不想做运维,对 DevOps 来说不是好事情。

 

最近, Scott Carey 发表了一篇调查文章,喊出了一些开发者的心声:“扯淡的DevOps,我们开发者根本不想做运维!”除此之外,软件工程师兼 DevOps 评论员 Sid Palas 也在推特上写道,“DevOps 已死,平台工程才是未来。”

 


他的核心观点是:开发者不想跟基础设施打交道,企业在发展过程中又需要控制自己的基础设施。只有平台工程,能将这两个相互矛盾的命题统一起来。

 

Honeycomb 的首席技术官 Charity Majors 对此也有同样的观点,她认为在软件演进过程中,我们将运维技能从开发技能中剥离出来,形成了两个不同的职业,但结果证明这是一个巨大的错误。因此 DevOps 出现了,我们用它来重新统一开发和运维。然而开发周期应该是一个企业中最稀缺的资源,所以应该将尽可能多的资源花在核心产品上。

 


Majors 认为,在过去,有的工程师写代码,有的工程师跑代码。而现在,工程师不仅编写代码,还要运行他们编写的代码。这导致软件工程师觉得他们必须对所有事情都了如指掌,大大增加了“认知负担”。

 

这迫使许多团队重新在自动化带来的自由与认知负担之间进行权衡。平台工程也因此越来越受关注和热议。PlatformCon 是第一个面向平台工程师的会议,一出现就吸引了超过 6,000 名与会者。Gartner 也在其 2022 年 8 月发布的软件工程炒作周期中添加了“平台工程”(图中第四个小圆点)。

 


什么是平台工程

 

按照“平台工程”社区主要贡献者和 Humanitec 的产品负责人 Luca Galante 的说法,平台工程是一门设计和构建工具链与工作流的学科。这些工具链和工作流可以为云原生时代的软件工程组织提供自助服务功能。平台工程师提供集成化产品,通常称为“内部开发平台(Internal Developer Platform)”,可以涵盖应用程序整个生命周期的所有操作需求。

 

内部开发平台(以下简称 IDP)是位于工程团队已有技术和工具之上的一层。它帮助操作人员进行系统性设置,并为开发人员提供自助服务。平台工程做好了,就好比是为个体开发人员铺就了金光大道,他们可以从 IDP 层获得合意的抽象等级。

 

从 DevOps 余烬中崛起

 

DevOps 和云原生的概念兴起之后,似乎是在突然之间,工程师们不得不掌握 10 种不同的工具、Helm 图表、Terraform 模块等,仅仅是为了在多集群微服务设置中的多个环境中部署和测试一个简单的代码更改。问题是,在整个工具链的演进过程中,这个行业似乎认为,在全球经济的几乎其他所有领域都被证明有效的劳动分工(Ops 和 Dev)并不是一个好主意。相反,DevOps 范式备受推崇,被视为实现高效设置的方式。

 

开发人员应该能够端到端地部署和运行他们的应用。“谁构建,谁运行”,这才是真正的 DevOps。这种方法的问题是,对于大多数公司而言,这实际上并不现实。

 

虽然对于像谷歌、亚马逊、Airbnb 这些比较先进的组织来说,上述方法很有效,但对于其他大多数团队而言,要在实践中复制真正的 DevOps 并不简单。最主要的原因是,大多数公司都没有像他们那样的人才库,也不会仅仅为了优化开发工作流和体验而做他们那样的资源投入。

 

与此相反,当一个普通的工程组织试图实施真正的 DevOps 时,往往会出现一系列的反模式。我们通过一个例子来看下,当组织决定实施 DevOps 并取消正式的 Ops 角色或团队时,许多开发团队中出现了什么情况。开发人员(通常是比较资深的)最终承担起了管理环境、基础设施等的职责。这就导致了这样一种情况:“影子操作”由那些在编码和产品开发方面才能体现出最大价值的工程师来执行。没有赢家。高级工程师现在要负责设置,并需要处理比较初级的同事的请求。在组织层面,其最昂贵和最有才华的资源现在正在被滥用,他们无法再以同样的速度和可靠性来交付功能了。



这类反模式已经为许多研究所证明,比如Puppet的DevOps现状报告或是最近Humanitec的基准测试研究。后面这份报告根据标准的 DevOps 指标(准备时间、部署频率、MTTR 等),对表现最好和最差的组织进行了分组。如下图所示,44%的低效组织存在着上述反模式,有些开发人员要自己完成 DevOps 任务,并帮助经验不足的同事。与此相比,表现最好的组织全部成功实施了真正的“谁构建,谁运行”方法。



那么,低效组织和高效组织之间的关键区别是什么?最好的团队是如何确保他们的开发人员能够运行自己的应用程序和服务,而不需要借助资深同事的不断帮助?你猜对了,他们有一个搭建内部开发平台的平台团队。Puppet的《2020年DevOps现状报告》清楚地说明了内部平台的使用与组织 DevOps 演进程度之间的相关性。



最好的工程组织就是这样做的。他们成立了内部平台团队,负责构建 IDP。在使用这些 IDP 时,开发者可以根据自己的喜好选择合适的抽象级别来运行他们的应用和服务。例如,他们喜欢摆弄 Helm 图表、YAML 文件和 Terraform 模块吗?很好,他们可以这么做。他们是不关心应用是否在 EKS 上运行的新手吗?没问题,他们可以通过自助服务为自己提供一个环境,这个环境包含了他们部署和测试代码所需的一切,而且不用管它在哪里运行。

 

铺就金光大道

这里所说的铺就金光大道是什么意思呢?让我们具体看下。如今,大多数 CI/CD 设置的重点都只是简单地更新镜像。CI 构建它们,更新配置中的镜像路径,完成。这覆盖了大多数部署用例。但是,当我们需要做一些基本工作流程之外的事情时,情况就开始变得更加复杂和耗时,例如:

  • 增加环境变量和修改配置

  • 添加服务和依赖项

  • 回滚和调试

  • 启动一个新环境

  • 重构

  • 添加/修改资源

  • 强制使用 RBAC


这样的例子不胜枚举。平台工程就是为所有这些需求铺好路。平台工程师提供粘合剂,将所有这些操作都绑定到一个一致的自助服务体验中,而不是让每个人什么操作都做,而且还必须了解整个工具链才能做到。

 

这种粘合剂就是内部平台。用 Evan Bottcher(https://martinfowler.com/articles/talk-about-platforms.html)的话来说,平台是“自助服务 API、工具、服务、知识和技术支持的基础,它们被定位成一个令人信服的内部产品。自主交付团队可以利用该平台更快地交付产品功能,减少协调时间。”

 

以这个定义为基础,我们可以将内部开发平台定义“一个自助服务层,旨在让开发人员可以独立操作组织的交付设置,使他们能够通过自助服务获取环境、部署、数据库、日志以及任何他们运行应用程序所需的东西。”

 

平台工程的原则

许多组织开始意识到内部开发平台和开发者自助服务所带来的好处。按照 Puppet《2021年DevOps现状报告》的说法,“平台团队的存在并不一定会解锁更高层次的 DevOps;不过,优秀的平台团队会扩大 DevOps 方案的好处。”

 

然而,招聘合适的人才来构建这样的平台和工作流程并不简单。更麻烦的是,要确保他们始终如一地向工程组织的其他部门提供可靠的产品,并将对方的反馈纳入 IDP。

 

以下是一些有用的原则,成功的平台团队和自助服务驱动的组织都是以此为主线。

 

明确使命和角色

要明确平台团队的任务。例如,“构建可靠的工作流,使工程师们能够独立地操作设置,并针对他们运行应用程序和服务所需的基础设施提供自助服务。”无论对你的团队来说哪块最重要,都要确保一开始就把这个定义好。为平台团队赋予一个明确的角色也极其重要,不应该将平台团队视为另一个按需提供环境的服务台,而应该将其视为一个专门为内部客户服务的产品团队。

 

将平台作为产品来对待

关于聚焦产品,我们再展开说明下。平台团队需要秉持产品思维,以内部客户也就是应用开发者的反馈为基础,专注于能够真正为他们提供价值的东西。要保证平台团队基于这个反馈循环来交付功能,而不被刚刚出现的新技术所吸引。

 

聚焦常见问题

对于内部其他团队共有的问题,平台团队要防止他们处理这些问题时重复发明轮子。找出这些常见问题的关键是:首先要了解导致开发进度放缓的开发痛点和阻力。这些信息既可以是通过开发人员反馈收集的定性信息,也可以通过查看工程 KPI 收集的定量信息。

 

粘合剂很有价值

通常,平台团队会被视为纯粹的成本中心,因为他们不为最终用户提供任何实际的产品功能。他们只是把我们的系统粘合在一起而已。这样的观点非常危险,当然,这种粘合剂非常有价值。平台工程师需要在内部肯定和宣传自己以及自己的价值主张。一旦你们为其他团队设计并铺就了金光大道,那么作为一个平台团队,你们所创造的主要价值是将工具链整合在一起,为工程师们提供顺畅的自助服务工作流。

 

不要重复发明轮子

同样,平台团队应该防止组织内的其他团队重复发明轮子,为同样的问题寻找新的创造性解决方案,他们自己也应该避免犯这样的错误。不管你自己开发的 CI/CD 解决方案多么优秀,商业供应商最终都会迎头赶上。平台团队应该经常问自己有什么不同之处。与其构建内部的 CI 系统或指标仪表板,并与能力强 20 或 50 倍的企业竞争,还不如专注于组织的特定需求,并根据这些需求定制现成的解决方案。无论如何,商业竞争对手更多的是针对行业中比较通用的需求进行优化。

 

现代工程组织

根据Puppet的《2021年DevOps现状报告》,“高度发展的组织往往会遵循 Team Topologies 模式”。

 

Matthew Skelton 和 Manuel Pais 合著的Team Topologies一书于 2019 年出版,在成功的工程组织中,成为最具影响力的现代团队设置蓝图之一。根据他们描绘的蓝图,团队应该围绕四种基本拓扑结构来设置。

 



  • 业务导向团队:与业务领域某个部分的工作流相匹配,处理核心业务逻辑。

  • 赋能团队:帮助业务导向团队克服障碍并检测缺失的功能。

  • 复杂子系统团队:在严重依赖数学/技术方面的专业知识时组建。

  • 平台团队:提供一个令人信服的内部平台,提高业务导向团队的交付速度。


如上图所示,平台团队与其他所有团队都是平行的,旨在确保从编码到生产的自助工作流的流畅运转。

 

什么时候应该考虑平台工程?

 

一个常见的误解是,平台工程只在大型团队中才有意义。如果你的团队只有 5 名开发人员,那么平台团队和 IDP 肯定是多余的,可一旦你的组织发展到超过 20-30 名开发人员,可能就应该考虑内部开发平台了,而且越早越好。

 

Luca Galante 对此强调道,“我听过无数团队的故事,他们构建 IDP 的时间太滞后了,并因此承受了许多本不必承受的痛苦,例如,唯一一名负责 DevOps 的员工休假,整个组织几周都不能部署。IDP 和招聘平台工程师可能是你今天就要考虑的投资。”

 

参考链接:

https://www.infoq.com/news/2022/10/platform-devops-summary/

https://thenewstack.io/devops-is-dead-embrace-platform-engineering/

https://www.honeycomb.io/blog/future-ops-platform-engineering

https://platformengineering.org/blog/what-is-platform-engineering

2022-10-11 16:0426144

评论 15 条评论

发布
用户头像
Self-service is a key defining characteristic for a good platform.
https://martinfowler.com/articles/talk-about-platforms.html
2023-03-01 13:21 · 北京
回复
用户头像
Gartner 认为 平台工程 Platform Engineering 是 2023 年的10大战略技术趋势之一,作为早期探索者的各大企业注定会走一些弯路,但同步也积累了不少经验,成为早期受益者,让战略先发优势得以体现。

关于更多事件的时间轴可以参考 平台工程主题的 awesome list https://github.com/toptechevangelist/awesome-platform-engineering
2022-12-13 11:09 · 广东
回复
用户头像
文章说的对,也可以了解一下DHorse(https://github.com/tiandizhiguai/dhorse), 是一个开源的基于k8s的开发平台。

2022-11-08 18:04 · 浙江
回复
用户头像
绝对标题党了,devops是文化,平台是对文化的实践
2022-10-23 09:41 · 北京
回复
用户头像
就我目前公司来看,内部平台我觉得是效能和基础组件团队联合起来定义公司的研发规范并流程化
2022-10-20 18:25 · 北京
回复
用户头像
这不就是做个好用的PaaS平台/运维平台?
2022-10-19 10:02 · 浙江
回复
用户头像
最近三年从事研发效能,中大公司为了降本增效,才能体现出这块的价值.当然等建设完成,就该进一步降本了.
2022-10-18 09:33 · 浙江
回复
用户头像
devops是一种理念,平台工程其实就是一个实践devops平台,一个paas服务,现在主流的云厂商都会提供这样的能力
2022-10-13 12:11 · 北京
回复
嗯,同感,好多年前阿里就已经如此了
2022-10-14 08:41 · 浙江
回复
用户头像
这么会起标题?来UC部报道
2022-10-12 09:53 · 浙江
回复
这不是不会取标题才用这个吗(😭)
2022-10-12 12:55 · 新加坡
回复
用户头像
个人觉得平台工程的目的就是对运维细节进行封装,让开发工程师们不用了解太多的底层实现,而是直接从运维需求方面进行运维操作。
2022-10-12 09:18 · 上海
回复
用户头像
平台工程?看起来更多是一种devops的具体实践形式。运维或效能团队打造平台从而减少开发者直接运维的成本。其实不管devops也好平台工程也罢,重要的是解决其针对的问题。
2022-10-03 09:14 · 北京
回复
用户头像
devops更多是流程和规范,100个程序员可以玩出200种花样,对企业是非常不利的。
2022-09-30 09:53 · 重庆
回复
没有更多了
发现更多内容

关于JVM,你必须知道的那些玩意儿

ClericYi

Redis系列(二): 连集合底层实现原理都不知道,你敢说Redis用的很溜?

z小赵

Java redis 高并发 高并发系统设计

618 我们狂欢的是什么?

Neco.W

拼多多 电商 京东 热门活动

锦囊篇|一文摸懂LeakCanary

ClericYi

故障演练利器之ChaosBlade介绍

心平气和

故障演练 故障注入

游戏夜读 | 《FPS关卡设计》

game1night

学习总结 - 第3周

饶军

ARTS-03 -- ARTS-04

NIMO

ARTS 打卡计划 ARTS活动

区块链系列教程之:比特币中的网络和区块链

程序那些事

比特币 区块链 网络 p2p

ARTS-week-4

youngitachi

ARTS 打卡计划 arts

再谈云原生:我的看法

lidaobing

云原生 k8s 中间件

我们是如何做go语言系统测试覆盖率收集的?

大卡尔

测试覆盖率 精准测试 Go 语言

锦囊篇|一文摸懂OkHttp

ClericYi

还有比二分查找更快的算法,面向接口编程Protocol,John 易筋 ARTS 打卡 Week 05

John(易筋)

swift ARTS 打卡计划 二分查找 binary search protocol

锦囊篇|一文摸懂EventBus

ClericYi

关于多线程,你必须知道的那些玩意儿

ClericYi

重学 Java 设计模式:实战命令模式「模拟高档餐厅八大菜系,小二点单厨师烹饪场景」

小傅哥

设计模式 小傅哥 重构 代码优化 命令模式

week3.学习总结

个人练习生niki👍

极客时间架构师训练营 - week3 - 作业 2

jjn0703

极客大学架构师训练营

第三周课后作业

iHai

极客大学架构师训练营

第三周学习总结

iHai

极客大学架构师训练营

架构师训练营第三周学习总结

CATTY

锦囊篇|一文摸懂ButterKnife

ClericYi

极客时间 - 架构师培训 -3 期作业

Damon

每周学习总结 - 架构师培训 3 期

Damon

week3.课后作业

个人练习生niki👍

单例模式 组合模式

Prometheus 2.19.0 新特性

耳东@Erdong

Prometheus

springboot整合Quartz实现定时任务(api使用篇)

北漂码农有话说

架构师训练营 - 学习笔记 - 第三周

心在飞

极客大学架构师训练营

架构师训练营 - 第三周命题作业

牛牛

极客大学架构师训练营 命题作业

架构师训练营 -week3- 作业

晓-Michelle

极客大学架构师训练营

DevOps 已死,平台工程才是未来_云原生_Tina_InfoQ精选文章