随着科技的不断发展，软件开发领域也在不断演进。在过去的几年里，DevOps一直是主流的开发和部署方法之一，但是随着技术的深入和需求的变化，越来越多的团队开始考虑将注意力从DevOps转向平台工程。本文将探讨为什么现在是时候考虑放弃DevOps，转向平台工程的怀抱。
DevOps的局限性
DevOps的主要目标是通过自动化和协作来缩短软件开发到部署的周期。它侧重于将应用程序和应用程序堆栈部署到各个环境中，包括开发、测试和生产环境。然而，DevOps的范围局限于应用程序层面，而忽略了底层的系统和平台。
DevOps团队通常关注于客户应用程序的部署，以确保它在各种环境中运行正常。然而，这种关注可能使得对内部工程和开发团队的支持相对较弱，因为他们更关心的是外部客户的需求。
还记得那句口号，“你构建它，你运行它”吗？根据设计，DevOps工程迫使开发人员成为工具专家，如果他们想正确使用它。这不应该成为他们核心活动和职责的一部分，因为它增加了认知负担。团队可能因为选择过多而产生的混乱、挫败感和开发瓶颈。
平台工程定义
Luca Galante 将平台工程定义为“设计和构建工具链和工作流的学科，这些工具链和工作流在云原生时代为软件工程组织提供自助服务功能。平台工程师提供了一个集成产品，通常被称为'内部开发人员平台'，涵盖了应用程序整个生命周期的操作需求。
平台工程的优势
平台工程采用一种更全面的方法，不仅关注应用程序的部署，还关注系统和平台的部署。与DevOps不同，平台工程师不仅仅是为外部客户部署系统，更是为内部工程和开发团队提供支持。他们的“客户”是内部团队，他们的目标是建立适用于整个内部工程/开发生态系统的强大平台。
平台工程团队不仅仅关心应用程序/应用程序堆栈，而是更注重整个系统的健康和稳定性。他们致力于提供灵活、高效的基础设施，使得内部团队能够更轻松地进行开发、测试和部署工作。这种全面的关注使得平台工程在支持内部工程团队方面更具优势。
平台工程可帮助开发人员通过结构化的工具链和工作流来管理 workload。这样一来，他们就可以获得一致、可靠的工具（平台），可用于自助服务和协作（即 DevOps）。这有助于团队避免因选择过多而产生的混乱、挫败感和开发瓶颈。
Devops vs 平台工程
DevOps 是一种概念思维方式，用于定义开发和运营协作方式。平台工程是创建一个具有定义的工具和工作流集的集中式平台。
| DevOps | 平台工程 |
|---|---|
| DevOps 是一种软件开发方法 | 平台工程是为 DevOps 工具和工作流创建一个平台的行为 |
| DevOps需要基于项目的思维方式 | 平台工程需要产品思维 |
| DevOps团队通常会选择自己的工具，然后负责掌握它们 | 平台工程根据开发人员的需求定义 DevOps 团队使用的工具 |
| DevOps 团队通常专注于交付应用程序的技术功能 | 平台工程团队专注于确定开发团队和其他平台用户所需的工具和工作流 |
| DevOps工程师有时会直接向外部受众（如客户）发布功能 | 平台工程师倾听并向内部团队解释平台 |
内部团队是平台工程的“客户”
在平台工程的视角下，内部工程和开发团队是他们的“客户”。这意味着平台工程师的关注点更多地集中在满足内部团队的需求上，而不仅仅是为了外部客户的利益。这种内部导向的方法可以更好地满足内部团队的特定需求，提高整个开发生态系统的效率和协作。
平台工程真的能推动DevOps成果吗？
与DevOps一样，平台工程的成功可能很难衡量。但最新研究表明，平台采用与DevOps成功之间存在相关性。事实上，在 2023 年平台工程现状调查中，94% 的受访者同意该概念正在帮助他们的组织更好地实现 DevOps 的好处
这些好处包括提高系统可靠性 （60%） 、提高生产力/效率 （59%） 和更好的工作流程标准 （57%）。它不仅让开发人员的生活更轻松：30% 的受访者表示，平台工程最能满足整个公司的需求，而不仅仅是单个部门。
平台工程可帮助开发人员通过结构化的工具链和工作流来管理该负载。这样一来，他们就可以获得一致、可靠的工具（平台），可用于自助服务和协作（即 DevOps）。这有助于团队避免因选择过多而产生的混乱、挫败感和开发瓶颈。
结论
随着软件开发环境的不断演变，放弃DevOps，转向平台工程是一个明智的选择。平台工程提供了更全面、内部导向的方法，强调整个系统和平台的健康和稳定性。通过将关注点从仅仅应用程序的部署转移到更广泛的系统和平台层面，团队可以更好地满足内部团队的需求，提高开发和部署的效率。在追求未来创新和持续发展的道路上，投入平台工程的怀抱将是一个明智的战略决策。
我是南哥，日常分享高质量文章、架构设计、前沿资讯，加微信拉粉丝交流群，和大家交流！
