平台工程不是为了取代 DevOps，而是 DevOps 的进一步演进和倒退。本文介绍了 DevOps 和平台工程，以及对于平安的意义。原文: Platform Engineering and Security: A Very Short Introduction
我是一名 DevOps 工程师，集体还是心愿 DevOps 依然有其意义，因为很显然，如今已是 ”DevOps 已死，平台工程万岁 ” 的时代了。
不可否认，自 2022 年以来，咱们更频繁的看到 ” 平台工程(platform engineering)”、” 开发者门户(developer portal)” 以及 ” 后盾(Backstage)” 等术语。
本文将答复几个根本问题：DevOps 真的死了吗？什么是平台工程？区别是什么？平台工程如何解决 DevSecOps/ 平安问题？
DevOps 已死？
简略来说，并没有。
如果我这么多年来在技术畛域学到了什么，那就是技术、框架和方法论从未真正沦亡，而是会成长、适应和倒退。
例如，想想麻利开发。你第一次据说麻利开发是什么时候？当初死了吗？这就是问题所在。
但某种程度上，DevOps 的确 ” 死 ” 了。尽管从传统意义上讲，DevOps 并没有从科技界隐没，但的确 ” 死 ” 了，因为许多尝试 DevOps 的公司和团队都没有达到预期。
不过这并不是什么新闻，因为早在多年前，技术钻研和征询公司 Gartner 的一位数据分析师就曾经预测，在整个 2022 年，75% 的 DevOps 打算将无奈达到预期指标，而到 2023 年，这一数字可能会增长到 90%。
但须要指出的是，这些 DevOps 打算的失败并不是因为技术上的挑战，而是因为信赖、所有权和团队单干等被忽视的人为因素。
DevOps 本应是解决传统经营孤岛中所有问题的银弹，让所有从新变得美妙。然而可怜的是，许多团队并没有达到最后预期，而且开发人员仿佛并不想从事运维工作：
开发人员不想从事运维？
偏心的说，这取决于你问的是谁。有些开发人员认为 DevOps “ 谁构建，谁运维 ” 的模式必定是无益的，甚至有时是必要的，而有些开发人员则基本不想接触运维。
Twitter 上有一项对于此问题的民意调查，330 名开发人员参加了考察，考察结果显示，41.8% 的受访者示意反对运维工作，42.1% 的受访者示意不反对，16.1% 的受访者示意无所谓。
因而，开发人员更违心防止与基础架构和运维打交道，这对 DevOps 来说是个坏兆头。在这种状况下，平台工程变得前所未有的热门。
平台工程
现在，非专业的最终用户常常被要求运维一系列简单的服务，这简直是不可能的。平台工程与 DevOps 一样，都是为应答日益简单的古代软件架构而呈现的。
DevOps 试图从文化角度解决软件开发生命周期 (SDLC) 中的合作和速度问题，即器重责任分担模式、继续成长和学习心态，激励团队单干、最佳实际和古代工具链，而平台工程则试图从另一个角度来解决问题：自助服务。
咱们来看一个具体例子：
团队中的开发人员须要为新创建的利用创立数据库，但他们可能并不齐全理解如何应用正确的自动化工具 (比方 Terraform) 在特定云服务商 (比方 AWS) 中创立关系数据库(RDS)，并非所有开发人员都晓得基础架构在哪里运行以及如何协调。
解决这个问题的 DevOps 办法是使团队具备足够的跨职能常识，让团队中的某个人把握 AWS 服务和基础设施即代码的专业知识，更重要的是领有适当权限，通过编写 Terraform 模块和在 AWS 中部署 RDS 来自动化配置云资源。
而对于平台工程，应该有一个作为 ” 外部开发人员门户 ” 的集成产品，这样开发人员就能够通过它以自助服务的形式申请 AWS 中的 RDS，平台将主动创立 RDS。
请留神，这只是一个例子。如果设计切当，外部开发人员门户网站能够实现更多功能。
简而言之，平台工程是一门设计和构建工具链和工作流集成产品的学科，涵盖了整个 SDLC 的操作需要，实现适度的开发人员自助服务，并为云原生时代的各个组织和团队找到适合的抽象层次。
平台工程 V.S. DevOps
尽管平台工程通过提供自动化基础架构操作的自助服务性能改善了开发人员的体验和工作效率，但并不适宜所有人，尤其不适宜小型团队 / 公司。即便团队决定购买外部开发人员门户网站作为服务，而不是从头开始构建，依然须要在幕后保护自动化和模板。想想之前在云上创立 RDS 的例子，团队须要具备保护 Terraform 模板的常识，以生成在 AWS 中创立 RDS 的模块。
如果团队和公司规模太小，不适宜发展平台工程，DevOps 能够更好的发挥作用。一般来说，在规模较小的环境中，合作更严密，节奏更麻利，组织摩擦更少。
对于平台工程和 DevOps，还有一点至关重要，那就是平台工程不会 ” 取代 ”DevOps，它的呈现不会让 DevOps 被忘记。
只管很多人说，随着平台工程的衰亡，DevOps 已死，但这并不是一种办法取代另一种办法的状况，而是两种办法能够联合在一起。咱们能够将平台工程称为 DevOps 的 ” 进化 ”，两者仍在促成雷同的指标，并能帮忙 DevOps 提高效率。咱们很可能依然会常常看到 DevOps 文化，而且许多软件工程组织也很可能会建设平台团队，从而将软件开发人员和 IT 运维人员凝聚在一起。
平安在新范式中的定位
说到 DevOps，就不能不提到平安(或 DevSecOps)，毕竟平安是头等大事。
DevOps 通过 ” 左移 ” 来解决平安问题。在传统软件开发办法中，与平安相干的工作只在 SDLC 的最初解决，而这可能会导致我的项目提早并且不可扩大，DevOps/DevSecOps 应用自动化工具尽可能早的在 SDLC 的每个阶段 ” 嵌入 ” 平安。
例如，在编写代码时，开发人员会思考潜在的平安问题，如在哪里存储 secrets 和凭证，以及如何从代码中平安的获取(而不是在将所有 secrets 推向生产之前进行最终审计 / 审查）。另外，在构建虚拟机镜像或容器镜像时，每次构建都会主动进行破绽扫描，并在发现任何破绽时进行修复(而不是在交付生产之前进行一次性扫描)。
这就是 ” 左移 ”。
所有这些以更麻利、反馈更快、更自动化的 ” 左移 ” 形式解决 secrets 的办法，在平台工程中依然被保持继承了下来，DevOps 和平台工程在这里并不矛盾。
只是在平台工程的帮忙下，外部开发人员门户网站能够将整个过程的自动化晋升到另一个档次。咱们来看两个具体的例子：
设想一下，当你想创立一个新的微服务时，外部开发人员门户网站能够应用现有模板疏导创立整个存储库，而不只是编写一些模板代码。而后通过技术手段结构 CI/CD 流水线、Dockerfiles 和 Kubernetes 清单，这不仅能为应用程序提供脚手架代码，还能提供 CI/CD 流水线、Dockerfiles、Helm charts 和 Kubernetes YAML，其中预配置的流水线遵循 DevSecOps 最佳实际，能扫描源代码中的硬编码 secrets，并对 YAML 等进行校验。
设想一下，你想存储一些 secrets。与其去弄清团队正在应用哪个 secrets 管理器，部署在哪里，以及是否有权限创立 secrets，还不如拜访与 secrets 管理器集成的外部开发人员门户，以自助服务的形式创立 secrets，而不用过多放心任何底层细节，这正是平台工程所能提供的形象水平。
设想一下，你想在云上启动一个新的虚拟机。与其从头开始编写自动化代码(或从现有代码库中复制粘贴)，而后在部署前审查平安组设置，还不如简略的拜访外部开发人员门户网站，点击一个按钮，而后应用由平台工程团队保护和爱护的模板来实现所有工作。
所有这些都是平台工程的魅力所在：
- 自助服务
- 适度形象
- 最佳实际和自动化
总结
本文探讨了 DevOps 和平台工程，它们之间的区别，以及新范式如何解决平安问题。
你好，我是俞凡，在 Motorola 做过研发，当初在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓重的趣味，平时喜爱浏览、思考，置信继续学习、一生成长，欢送一起交流学习。为了不便大家当前能第一工夫看到文章，请敌人们关注公众号 ”DeepNoMind”，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的反对和能源，激励我继续写下去，和大家独特成长提高！
本文由 mdnice 多平台公布