2025 年内部开发者平台 (IDP) 深度指南

你的 Internal Developer Platforms（IDPs）指南

你是否常常觉得，自己花在折腾基础设施和 DevOps 工具上的时间，比真正写代码还多？你并不孤单。管理基础设施、部署、安全等流程，都会拖慢开发者的敏捷性，并损害开发者体验。

如今，已经有了 Internal Developer Platforms（IDPs）——一种旨在简化软件开发管理环节的应用，让你可以专注于编写和交付代码。通过抽象掉繁杂的基础设施问题，IDPs 为开发打造了一条自助式的“黄金路径”。

什么是 IDP？

从本质上说，IDP 是一个自助式系统，将开发团队所需的一切集中到一起。你可以把它想象成一个统一的控制台，在这里可以访问代码仓库、CI/CD 流水线、服务目录、数据库、云基础设施和监控工具。IDPs 还会与知识库（如文档和运行手册）集成，并接入 GitHub、Jira 和 CI/CD 系统等流程工具。

这种中心化意味着开发者花在“怎么做”这类问题上的时间更少，而花在构建功能上的时间更多。但它不只是一个聚合器——IDP 允许 DevOps 团队将最佳实践和安全控制“写入代码”，不再依赖工程师去记住公司的流程规范。

采用 IDP 的战略考量

在考虑将 IDP 引入你的组织吗？这是一个重要决定，而你不可避免地会面临经典的“build vs. buy”两难。以下是一些需要权衡的关键战略因素：

1. Integrations

首先，工具链集成是不可妥协的。你的 IDP 需要与现有的一切良好配合——比如源代码管理（GitHub/GitLab）、CI/CD、云提供商（AWS、GCP、Azure）、工单系统（Jira、Linear 等），以及可观测性工具（Datadog、HyperDX、Prometheus）。它应该聚合这些工具，而不是迫使你进行痛苦的重写，或引入兼容性问题。

2. 资源投入

接下来，考虑你在 build 与 buy 之间的资源投入。如果你有一支规模可观、能力成熟的平台工程团队，并且确实有独特需求，那么自己构建（也许基于像 Backstage 这样的开源基础）可以提供最大的可定制性。然而，这需要大量工程投入来搭建和扩展。

对于更小的团队，或者那些希望快速见效的团队来说，现成的 SaaS 方案通常更合理，它可以减轻维护负担，并可能快速带来价值。归根结底，这取决于成本：在商业解决方案的许可费用、内部工程时间，以及自行构建的机会成本之间取得平衡。

3. 定制化

然后，你必须权衡定制化与开箱即用功能之间的关系。像 Backstage 这样的开源 IDP 通过插件和自定义代码提供了极强的可扩展性，如果你想定制一切，它会很合适。SaaS 方案虽然实现更快，但通常带有预置功能，其可定制性可能要弱得多。

4. On-Premises vs Cloud Hosted

然后还有本地部署与 SaaS 的问题，尤其在高度受监管的环境中更为相关。如果你的平台包含敏感元数据，并且出于合规要求需要在内部托管，那么自托管或开源方案很可能是必需的。不幸的是，许多 SaaS IDP 都是云托管的，所以你的安全团队可能会对这种模式感到不放心。

5. Security and Governance

不要忽视安全、访问控制和治理。一个健壮的 IDP 需要可靠的身份验证和授权（例如与 Okta/AD 或其他基于角色的访问控制进行单点登录集成），以及审计日志和合规功能。这能确保你可以控制谁能做什么。

6. Scalability and Performance

对于拥有数百或数千名开发者的大型组织来说，可扩展性和性能至关重要。平台能否处理数以万计的目录条目（微服务、组件），并且仍然保持快速搜索？

7. Developer Experience

最后，开发者体验（DevEx）和采用情况也很重要。IDP 的全部目的就是改善 DevEx，因此门户的用户体验可能决定成败。一个简洁、直观的界面和清晰的工作流，会推动工程师更高的采用率。如果 IDP 笨重或过时，开发者可能会忽略它，从而违背其初衷。

对比顶级 IDP 工具

现在，让我们比较一下 IDP 领域的一些关键产品，它们各自都有独特的优势和适用场景：

Backstage

如果你追求最大的灵活性和开源生态，那么你绝对应该看看这位重量级选手——Backstage。Backstage 最初由 Spotify 开发，如今作为一个 CNCF project 维护，它是一个支持良好的开源框架，用于构建你自己的内部开发者门户。开箱即用，它提供用于跟踪服务的 Software Catalog、用于内部文档的 TechDocs，以及用于一致性项目启动的 Software Templates（Scaffolder）。它的插件架构极其丰富，几乎可以与任何工具集成（例如，使用 Infisical 进行 secrets management）。它没有许可成本，而且你可以完全掌控自己的数据。

不过，这种灵活性伴随着很高的实施和维护成本。对许多公司来说，让它完全投入生产可能需要 6 到 12 个月，而长期维护可能还需要 3 到 15 名全职工程师。由于这是一个你需要学习的新框架，因此需要克服一定的 learning curve。许多团队还抱怨，如果没有适当的整理，它会变成一个“data dump”，进而导致采用问题。我听说过几家公司的情况：它们走完了整个实施流程，最终却只有 10% 的工程师在使用这个 IDP。话虽如此，如果你喜欢这个理念但不喜欢运维开销，像 Roadie 这样的托管 Backstage 方案可以负责托管和升级，但会产生持续费用（例如，约 ~$22/开发者/月）。根据你的情况，这可能是更合适的选择。

Port

Port 是一个商业 SaaS IDP，以易用性和快速上手见长。它定位为一种点选式解决方案，让你通过 Web UI 使用“Blueprints”配置软件目录和工作流。你可以获得一个全面的软件目录，其中包含丰富的实体关系，以及强大的自助操作；这些操作可通过 GitHub Actions 或 Jenkins 等后端触发你现有工具链中的自动化。它还内置了用于衡量工程标准合规性的 scorecards。完全托管意味着你的团队维护负担很低，因为 Port 会处理托管、扩展、更新和安全。一些团队甚至报告称，他们在几天内就让概念验证跑了起来。

但要注意：虽然它很灵活，团队也可能会在构建、调整和维护 blueprints 上花费太多时间，从而在设置中引入复杂性。如果没有强大的集成，目录维护可能会变成手动操作。它也是一个多租户 SaaS 方案，因此对于某些高度受监管的环境来说，数据方面的考量可能是个问题。而且对于更大的组织来说，规模化后的成本可能会变得“贵得离谱”，有传闻称企业定价大约是一些竞争对手的两倍。

Cortex

Cortex 是一个 SaaS IDP，定位为用于跟踪软件健康状况和标准的“enterprise-class”解决方案，重点在于“执行工程最佳实践并提供领导层洞察”。它将一个健壮的 service catalog（与 git repos、CI pipelines、incident trackers 集成）与强大的 scorecards 和标准跟踪结合起来，以确保服务满足质量基准，例如测试覆盖率、SLOs、安全检查，通常还带有自动评分和告警。Cortex 还提供面向开发者的洞察，例如服务健康指标和定向告警。它从根本上是为 50 人以上、优先考虑微服务治理的组织而构建的。

它的主要限制是数据模型相对刚性；如果你的组件不符合其预定义类型，你可能不得不强行套进去。与 Port 或 Backstage 相比，它也不太侧重任意的自助操作或复杂的异步工作流。如果没有完全自动化，维护 Cortex 可能会涉及大量手动数据输入。在大型组织中的全面推广可能需要六个月或更久，而且工程师需要面对明显的学习曲线。并且要准备好接受更高端的企业定价，有些经验性说法称，对于大型组织，每用户每月大约为 $65–$69。

OpsLevel

OpsLevel 是另一个流行的 SaaS IDP，专注于提供一个完全托管、开箱即用并带有强大自动化能力的门户。OpsLevel 提供类似 Backstage 的能力，但没有那些麻烦，简化了设置和推广。它强调自动化的服务目录，通过连接 git repositories、Kubernetes clusters 和云账户等来源，自动摄取并更新服务，从而减少手动工作。与 Cortex 和 Port 类似，它也包含用于合规性的 standards 和 scorecards（Checks），以及用于新服务搭建的 self-service actions 和 service templates。此外，它的 Campaigns 功能使跨组织变更的规划、分发计划和跟踪变更变得更容易。

不过，它是一个专有平台。这也意味着你不能修改核心软件（但对于不能使用 SaaS 的公司，也有 self-hosted 选项）。而且虽然在配置上相当灵活，但与 Backstage 相比，它提供的“无限”定制要少得多；在 Backstage 里，你可以编写任何你想要的插件。但这些取舍换来的是工具的简洁性，而且定价也相当合理，每用户每月 $39。

总体而言，OpsLevel 是该类别中的一个全能选手，功能涵盖 catalog、checks、templates、actions 和 docs。

Atlassian Compass

作为一个较新的参与者（于 2023 年发布），Atlassian Compass 自然与 Atlassian 套件紧密集成，比如 Jira、Confluence 和 Bitbucket。它提供一个软件组件目录，并链接到你的文档、问题和仓库，充当你工程资产的集中索引。与其他 IDP 类似，它也包含用于软件健康状况的 scorecards。作为 Atlassian 产品，它可以像你预期的那样与 Jira Software 原生集成。上手非常容易，甚至提供了慷慨的免费方案（最多 3 个 full users）以及低成本的 Standard 方案（约每用户/月 ~$7）。

它的主要局限在于过于以 Atlassian 生态为中心，这意味着与非 Atlassian 工具的集成广度，可能不如更工具无关的平台。与更成熟的 IDP 相比，它也缺少一些高级自动化功能，主要充当 catalog 和跟踪工具，而不是完整的平台自动化解决方案。此外，它的定制性也更弱。你受制于 Atlassian 对 Compass 的产品路线图。虽然我能看出他们正通过 Premium plans 为企业使用做准备，但它相对较新，因此大规模参考案例可能还不容易找到。

其他值得关注的平台和概念

除了这些主要竞争者之外，IDP 领域也很热闹。Humanitec 就是一个例子，它更像是一个 Platform Orchestrator，而不是一个门户本身。它专注于作为后端引擎，动态提供和管理基础设施，创建即时生成的开发环境。它非常适合在带有 guardrails 的情况下实现真正的自助式部署，并且通常会与像 Backstage 这样的门户搭配使用，后者负责 UI。在这种架构中，Humanitec 提供 APIs，而 Backstage 是前端。Humanitec 还提供多种方式来 integrate with Infisical 进行 secrets management。

其他值得一提的包括 Roadie（一个 SaaS 托管的 Backstage 方案）、Harness IDP（Harness 自己基于 Backstage 的解决方案，带有 CI/CD 集成），以及各种 PaaS 产品，例如 Mia Platform、Qovery、Mogenius 和 Nullstone，它们将完整的云平台与 developer portal 组件打包在一起。虽然我重点介绍的产品是我个人的首选清单，但为了完整性，研究这些其他参与者也值得一做。

关于 AI 准备度的想法

采用 IDP 的目标，是将你 DevOps 的所有数据汇集起来，让工程师可以在一个地方对其进行统一理解。不过，这并不会减少他们需要处理的数据量。Vibe coding 很棒，但它只关注代码，而不是代码周围那些繁杂的 DevOps。用不了多久，我们就会拥有能辅助 DevOps 任务、甚至调试问题的 AI 驱动工作流。如果你的 DevOps 数据已经因为使用 IDP 而集中到一个地方，那么这个世界更有可能成为现实。

结论

归根结底，采用 IDP 是为了赋能你的工程师并加速软件交付。正确的选择，说到底取决于你组织的独特需求：现有工具链、团队规模和技能、所需的定制化程度，以及预算。

如果这一切听起来令人望而生畏，请记住，Internal Developer Platforms 是一项长期投资，而不是一次性项目。你可以从小处开始，也许先从一个 service catalog 或一个新服务模板开始，然后逐步迭代。这样可以让新开发者更快上手，减轻 DevOps 团队的运营负担，并提升各项服务的一致性和可靠性。

• 原文链接： infisical.com/blog/navig...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～