泉州企业制作网站,咨询公司成本费用包括哪些内容,微信h5在哪个网站做,能上国外网站的免费dns平台工程不是为了取代DevOps#xff0c;而是DevOps的进一步演进和发展。本文介绍了DevOps和平台工程#xff0c;以及对于安全的意义。原文: Platform Engineering and Security: A Very Short Introduction 中国云南大理的日落 我是一名 DevOps 工程师#xff0c;个人还是希… 平台工程不是为了取代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 上有一项关于此问题的民意调查[1]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并设个星标吧如果能一键三连(转发、点赞、在看)则能给我带来更多的支持和动力激励我持续写下去和大家共同成长进步 参考资料 [1] Twitter上关于DevOps的调查: https://twitter.com/luca_cloud/status/1562349679660122112 本文由 mdnice 多平台发布
