最近某位大神在推特上发了一个帖子,结果引来了国内众多卖课机构、培训机构的狂欢,开始贩卖焦虑,其实「平台工程」也不是什么特别高深莫测的东西 。闲得无聊,把这位大神的几个帖子薅了下来,你看过之后就会觉得没啥,都是熟悉的东西 。
Sid Palas & 平台工程这位大神的名字叫 Sid Palas,一位专门做 DevOps 和 Cloud infra 相关工作的小伙伴 。为了让大家了解他,他的 github 我附在最后了 。下面就是这个非常有意思的帖子 。原帖可以到推特上去围观 。共有六部分,第一部分我贴了原图,后面的五部分我把文字复制了过来 。
文章插图
DevOps is dead , long live Platform Engineering! 1) Developers don't like dealing with infra 2) Companies need control of their infra as they grow. Platform Engineering (and Internal Developer Platforms) enable these two facts to coexist.
DevOps 已死,平台工程永存 。1) 开发人员不喜欢与基础设施打交道 2) 公司在发展时需要控制他们的基础设施 。平台工程(以及内部开发者平台)可以同时满足这两个诉求 。
Fact 1: Most developers don't like dealing with infrastructure. They want to write code and run it somewhere but don't care much where that is. Functions as a Service (e.g. Lambda) or Platforms as a Service (e.g. Vercel) provide this experience.
事实 1:大多数开发人员不喜欢处理基础设施 。他们想编写代码并在某个地方运行它,但不太关心运行在哪里 。函数即服务(例如 Lambda)或平台即服务(例如 Vercel)提供了这种体验 。
文章插图
Fact 2: As a company/organization grows, its needs may "outgrow" the constraints imposed by the FaaS and PaaS offerings. The challenge then becomes moving up the control axis without exiting the Developer Comfort Zone. This is where platform engineering comes into play!
事实 2:随着公司/组织的发展,其需求可能会“超出”由 FaaS 和 PaaS 产品施加的限制 。然后挑战变成在不离开开发者舒适区的情况下向上移动控制轴 。这就是平台工程发挥作用的地方!
文章插图
Platform engineers build the tooling and abstractions around the complex infrastructure configurations such that most software engineers don't need to worry about those aspects as much. The resulting system is what is known as an "Internal Developer Platform" (IDP)
平台工程师围绕复杂的基础架构配置构建工具和抽象,这样大多数软件工程师就不必担心这些方面 。由此产生的系统就是所谓的“内部开发者平台”(IDP)
文章插图
The exact form of an IDP will vary greatly from one organization to the next. At a small company, it could be a set of helm charts that prescribe best practices for deploying services. At a large company, it might be a fully automated Infrastructure as Code solution.
IDP 的形式因组织而异 。在一家小公司,它可能是一组说明部署服务最佳实践的 helm charts 。在一家大公司,它可能是一个完全自动化的基础设施即代码的解决方案 。
The key is that it provides the control the company needs while keeping the DevOps effort within the Developer Comfort Zone!
关键是它提供了公司所需的控制,同时将 DevOps 工作保持在开发人员舒适区内!
文章插图
平台工程价值观Sid Palas 的观点非常简单、直接、好理解:平台工程团队以及他们负责的内部开发者平台,向下维护底层基础设施,向上给开发人员提供服务 。开发人员自助式使用这个平台,避免直接与底层基础设施打交道 。
经验总结扩展阅读
- DevOps | 如何快速提升团队软件开发成熟度,快速提升研发效能?
- DevOps|1024程序员节怎么做?介绍下我的思路
- DevOps|从特拉斯辞职风波到研发效能中的不靠谱人干的荒唐事
- Azure DevOps Pipelines部署.Net Core 应用到Kubernetes
- 云原生时代的DevOps平台设计之道
- 没有使用IaC的DevOps系统都是耍流氓
- 自我效能感的影响包括
- 如何0到1构建DevOps?
- 十分钟速成DevOps实践
- 「产品运营」研发效能之DevOps平台如何运营?