平台工程不是为了取代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多平台发布