对开发人员门户、服务目录和内部开发人员平台的混淆会产生真正的后果。
如果我不得不说出一些人对平台工程的最大误解，那就是认为成功的平台工程努力的结果是一个闪亮的用户界面，有很多可以点击的按钮和可以查看的仪表板。
许多人将开发人员门户和服务目录与内部开发人员平台 (IDP) 混为一谈，但它们并不相同。混乱会产生真正的后果。充其量，这个闪亮的 UI 只能让组织获得他们可以从平台工程中获得的投资回报 (ROI) 的一小部分。
2022 年，我与大约 300 个平台工程团队进行了交谈。其中许多团队都是通过构建开发人员门户开始他们的平台工程之旅的。然而，对于其中 95% 的团队来说，其他平台化举措会对开发人员的生产力和投资回报率产生更大的影响。不到 20% 的团队看到开发人员实际采用和使用开发人员门户。
2022年，Gartner明确了开发者门户与内部开发者平台的关系：
“内部开发人员门户作为开发人员可以发现和访问内部开发人员平台能力的界面。”
例如，Netflix 在其现有平台工具之上构建了一个开发人员门户。
内部开发人员平台是平台工程团队绑定到开发人员黄金路径的所有技术、工具和流程的总和。黄金路径减少认知负担并通过设计推动标准化。 IDP 甚至不需要用户界面。 IDP 不仅仅是聚合信息并显示它——从配置和基础设施管理到环境和部署管理。设计 IDP 就是倾听开发人员每天的实际需求，并构建满足这些需求的解决方案。开发人员门户可以可视化底层平台，但它不是 IDP 的必要组件。
开发人员门户或服务目录是一个用户界面，它从多个 API 中提取数据并将它们整合到不同的视图中。服务目录向您显示可用服务的列表，它们具有哪些 API 以及服务的所有者。它从 GitHub、事件跟踪系统和持续集成 (CI) 中提取和聚合元数据。服务目录通常有一个“模板库”，它或多或少是 GitHub 模板和仪表板的新特集合。
如果开发人员门户和服务目录不是必需的，为什么那么多组织首先专注于构建它们？以下是我见过的一些最常见的原因：
- 感觉很明显：当组织开始他们的平台之旅时，他们倾向于考虑按时间顺序缓解痛点。首先想到的是您首先完成的任务。对于应用程序的生命周期，这可能是创建服务。对于开发人员来说，通常是入职。许多组织选择首先在这里开始自动化。
- 可呈现：仪表盘是您可以向您的经理展示的东西，尤其是当他们没有技术背景时。与重组配置管理相比，可视化更容易解释和销售。但这并不意味着它更有意义。
- 每个人都对接口有自己的看法：虽然平台工程领域中很少有人深入了解如何在底层技术和配置管理等真正痛点方面构建内部开发人员平台，但更多人有自己的看法在接口上。因此，在开发人员体验中，更多的是谈论接口，而不是真正深层次的问题。
在将时间和资源投入开发人员门户和服务目录之后，许多组织对结果感到失望。原因如下：
- 开发人员讨厌“又一个界面”。他们希望留在代码中，在他们的 git-push 通道中，并且快速且不间断地运行。您可以构建最漂亮的 UI，但这并不意味着任何人都会定期查看它。我查看了一个非常大的电子商务玩家的门户网站的使用指标，发现平均而言，开发人员每年只使用一个功能（搜索）一次来检查他们正在构建的东西之前是否已经构建过。
- 有形的好处很少。我听到的最常见的用例是“我们想要标准化新服务的创建”。假设您每年创建 1,000 个疯狂的新微服务。你今天是怎么做到的？可能只是通过克隆 GitHub 模板。因为门户本身基本上只是 UI 框架，它们所做的只是调用其他 API。因此，如果您实现“通过单击按钮创建新服务”的功能，此按钮将调用 GitHub 模板 API 并克隆链接的示例存储库。使用最常用的开源框架构建门户实际上需要六个月的时间，至少需要两名全职员工 (FTE)。但是你的影响在哪里？您是否为每个服务创建获得了 10 秒的时间？一分钟，甚至？假设出于某种神奇的原因，它是 1 分钟，我们每年支付 100,000 美元的 1,000 项服务和两个 FTE。那么你的投资回报率仍然是惊人的 -80%，记住这是假设我们每年创建 1,000 项服务！恭喜，你只是浪费了时间。
- 门户网站和服务目录的实施和更新也非常复杂。开发人员会不断规避，有错误数据的仪表板可能比没有仪表板更糟糕。您将花费大量资源和时间来尝试使内容保持最新。
您不应专注于构建开发人员门户或服务目录，而应优先考虑对开发人员最有利的功能。您可以通过采用产品方法来确定您的组织需要哪些功能。使用产品方法，您不会从构建一些有影响力的人告诉您的东西或任何感觉显而易见的东西开始。相反，您从用户研究开始。去找你的开发人员，问他们需要或想做什么。
然后，您有责任优先考虑这些问题。一种方法是记录开发人员每 100 次部署执行某项任务的频率以及需要多长时间。您最终会得到一张类似于下图的表格。
样本计算
| 步骤 | 频率（占部署的百分比） | 以小时为单位的开发时间（包括等待和错误） | 操作时间（小时） |
|---|---|---|---|
| 添加/更新应用程序配置（例如，环境变量） | 5%* | 1h* | 1h* |
| 添加服务和依赖项 | 1%* | 16h* | 8h* |
| 添加/更新资源 | 0.38%* | 8h* | 24h* |
| 重构和文档架构 | 0.28%* | 40h* | 8h* |
| 由于受阻环境等待 | 0.5%* | 15h* | 0h* |
| 提升环境 | 0.33%* | 24h* | 24h* |
| 入职开发人员、再培训和交换团队 | 1%* | 80h* | 16h* |
| 回滚失败的部署 | 1.75% | 10* | 20* |
| 调试、错误跟踪 | 4.40% | 10* | 10* |
| 等待其他球队 | 6.30% | 16* | 16* |
*每 100 个部署。 来源: https://humanitec.com/blog/top-10-fallacies-in-platform-engineering
您可以使用此表计算出内部开发平台的投资回报率。
在大多数情况下，我发现两项更改会产生最大的效果。确保您确实设置了基本的 CI/CD 流程可以减少工作量并提高效率。将您的配置管理从“静态”重组为动态配置管理，可以通过设计实现标准化、关注点分离和认知负荷较低的持续自助服务。
这并不是说没有充分的理由来构建开发人员门户。如果您的开发人员正在创建数量惊人的服务和资源，并且需要对它们进行分类以进行内部源代码工作，那么门户网站将非常有用。但是，拥有获得正投资回报率所需的数千种服务和开发人员的组织并不多。
有时您必须构建开发人员门户，因为管理层告诉您这样做。你别无选择。但是，如果这些情况都不适合您，请不要浪费时间专注于将开发人员门户作为起点。相反，从构建您的 IDP 开始。您的开发人员会感谢您！