平台工程对决：是否需要IDP？

内部开发者平台是平台工程的基石，还是只是另一个被过度炒作的工具？技术专家权衡其优缺点。

译自 Platform Engineering Face-Off: To IDP or Not To IDP?，作者 Ido Neeman; Eran Bibi。

平台工程已成为现代科技讨论中最热门的话题之一，通常被吹捧为开发者体验 (DevEx) 的未来——有些人甚至认为它标志着 DevOps 的终结。（DevOps 已死！平台工程万岁！）

但平台工程究竟意味着什么？内部开发者平台 (IDP) 的概念又如何融入其中呢？观点差异很大，一些人提倡将 IDP 作为平台工程的基石，而另一些人则告诫不要盲目跟风，指出过度简化的风险。

开发内部开发者平台需要什么

在我们开始讨论是否采用 IDP 之前，让我们首先统一术语。IDP 旨在集中和简化工程团队与基础设施、工具和流程交互的方式。

它们提供了一个单一界面——通常结合自动化、自助服务功能和文档——以简化工作流程并减少开发人员的认知负担。像 Port 和 Humanitec 这样的商业解决方案提供了具有强大支持和集成的现成平台，而像 Backstage 这样的开源选项则允许团队自定义和构建自己的门户。但是，采用、实施和维护 IDP 需要在时间、专业知识和跨团队协调方面进行大量投资。

此过程通常涉及：

• 广泛的规划: 团队必须仔细评估其当前的工作流程、开发人员的痛点和基础设施需求，以设计一个符合其独特要求的平台。
• 跨团队协作: IDP 会影响多个利益相关者——从开发人员和运营团队到产品经理——需要达成共识并持续协调以确保成功实施。
• 定制开发和集成: 虽然商业解决方案可能提供即插即用的功能，但要根据具体的组织需求定制 IDP，通常需要大量的定制、与现有工具的集成和大量的测试。
• 持续维护: IDP 不是“设置后即可忽略”的解决方案。它需要定期更新、监控和调整，以跟上不断发展的技术栈、团队需求和业务目标。
• 文化认同: 除了技术实施之外，IDP 的成功还取决于培养一种采纳和参与的文化，确保团队了解其好处并将其融入到他们的日常工作流程中。

组织必须仔细权衡初始设置、长期维护和潜在收益之间的利弊，以确保平台真正满足其独特需求。

考虑到所有这些，可以理解为什么双方对是否应该采用 IDP 都有强烈的意见。因此，我们将提出相反的论点，说明为什么您应该或不应该为您的组织考虑 IDP。

内部开发者平台：优缺点

让我们深入探讨这场辩论，探讨双方观点——为什么 IDP 可能是您的团队所需的解决方案，以及反对依赖 IDP 的论点。

Eran：支持 IDP

IDP 的支持者认为，它们不仅仅是工具，而是一个改变开发人员与基础设施和流程交互方式的框架。以下是 IDP 可能是正确选择的原因：

1. 简化的自助服务: IDP 使开发人员能够独立访问和配置资源，减少瓶颈，并允许团队专注于构建，而不是等待。
2. 一致性和标准化: 通过集中文档、工作流程和模板，IDP 推广最佳实践并减少错误，使团队更容易协作和吸纳新成员。
3. 更好的开发者体验: 平台工程的核心承诺是改善 DevEx。有效的 IDP 为开发人员提供单一视图，简化他们的工作流程并消除摩擦点。
4. 可扩展性: 随着组织的增长，管理基础设施和流程变得越来越复杂。IDP 提供了一个可扩展的解决方案来维持秩序和效率，确保平台团队不会不堪重负。

Ido：IDP 不是灵丹妙药

IDP 的批评者经常将其与 Kubernetes 被誉为微服务最终解决方案，但很快又成为一项复杂挑战本身的做法进行类比。类似地，IDP 通常被吹捧为平台工程的“灵丹妙药”，而实际上，它们可能会掩盖更深层次的组织问题，或者导致比解决的问题更多的问题。以下是反对者的观点：

1. 过度关注工具: 平台工程并非关于特定工具，而是关于解决改进 DevOps 的 DevEx 的更广泛挑战。IDP 可能使这项计划沦为一个实施细节，从而掩盖了更大的图景。此外，您可能不需要为旧的技巧使用新的闪亮工具。例如，现有开发者工具链中流行的工具——例如 Jira、Harness 和 Datadog——都有“为 IDP 编排”选项。拥有一个“纯粹的”IDP 只是引入了另一个工具，而现有工具可以完成这项工作。
2. 供应商锁定: 许多 IDP 解决方案都与特定的供应商或生态系统绑定，这使得组织难以随着其需求的变化而转向。最初作为简化解决方案的东西可能会变成一种新的依赖形式。
3. 虚假的万能承诺: IDP 的说法通常简化了平台工程的复杂性。部署 Backstage 或 Port 等工具并不是魔杖，它不会自动解决所有 DevEx 挑战。如果不解决组织流程、工作流程和文化问题，门户就会成为一个闪亮但空洞的产物。
4. 与团队需求不匹配:并非所有组织或团队都需要相同级别的抽象或自助服务。对一家公司有效的 IDP 对于另一家公司来说可能是多余的——或者完全无关紧要的。

超越工具

这场辩论的双方都强调了一个关键事实：平台工程不仅仅是关于工具。它还关乎解决现代软件开发带来的系统性挑战——创建自助服务、可重复的基础设施，并培养协作和创新的文化。

您不希望仅仅因为 IDP 是一种潮流，或者因为供应商承诺它会解决您所有的问题而采用它。相反，目标是评估您独特的挑战，了解平台工程可以为您的组织带来什么成就，并选择符合您愿景的工具或方法。

决策时间！

IDP 的对抗象征着科技领域一场更大的讨论：新工具的诱惑与它们旨在解决的根本原则之间的张力。无论您是否选择 IDP，关键是要专注于目标：赋能开发者，简化运营，构建弹性、可扩展的平台。像 IDP 这样的工具可以成为强大的推动者——但只有在深思熟虑并在正确的环境中使用时才能如此。