type
status
date
slug
summary
tags
category
icon
password
编者：本文原作者是一家平台编排器(一种自动组织编排infra资源的infra)公司的CEO，他们帮助一些公司实施平台工程时发现的规律：刚开始客户会对搭建可见的门户(Portal)非常感兴趣，慢慢会回到解决环境配置、云资源依赖的编排等“更实际”的问题上来。在一些访谈里他建议500人及以上研发团队，才有必要投资Backstage为代表服务目录Portal。IDPs是关于建设面向内部的API，门户Portal是IDPs之上偏薄的一层。
对开发者门户、服务目录和内部开发平台的混淆带来了真正的问题。
如果我必须说出一些人对平台工程最大的误解，那就是成功的平台工程战略结果是一个有很多按钮可以点击和仪表板可以查看的闪亮用户界面。
许多人将开发者门户和服务目录与内部开发平台(IDPs)混为一谈，但它们并不相同。这种混淆带来了真正的问题。充其量，那个闪亮的 UI 只允许组织获得它们可以从平台工程中获得的投资回报(ROI)的一小部分。
在 2022 年，我与大约 300 个平台工程团队进行了交流。这些团队中的许多人开始他们的平台工程之旅是从构建开发者门户开始的。然而，对于它们中的 95%，其他平台化举措本可以对开发者的生产力和投资回报产生更大的影响。不到 20% 的团队看到开发者实际采用和使用开发者门户。
开发者门户(Developer Portals) vs. 服务目录(Service Catalogs) vs. IDP(Internal Developer Platforms)
在 2022 年，Gartner 阐明了开发者门户和内部开发平台之间的关系： “内部开发者门户充当开发者发现和访问内部开发平台能力的界面。”
例如，Netflix 在其现有的平台工具之上构建了一个开发者门户。 内部开发平台是平台工程团队为开发者构建的所有技术、工具和流程的总和，它们结合在一起形成了一条黄金路径。这条黄金路径通过设计减少了认知负荷并推动了标准化。一个内部开发平台甚至不需要有用户界面。内部开发平台远不止于聚合信息和展示信息——它们包括从配置和基础设施管理到环境和部署管理等方面。设计内部开发平台是关于倾听开发者在日常工作中实际需要什么，并构建满足这些需求的解决方案。开发者门户可以可视化底层平台，但它不是内部开发平台的必要组成部分。
开发者门户或服务目录是一个用户界面，它从多个 API 中提取数据，并将它们与不同的视图进行对比。服务目录向您展示了可用服务的列表，包括它们具有哪些 API 和服务的拥有者。它从 GitHub，工单系统和持续集成（CI）中拉取并聚合元数据。服务目录通常具有一个“模板图库”，这是一个或多或少的精美 GitHub 模板和仪表板集合。
为什么组织专注于开发者门户和服务目录？
如果开发者门户和服务目录并非必需，为什么许多组织还是首先专注于构建它们呢？以下是我见过的一些最常见的原因：
- 它看起来显而易见：当组织开始他们的平台之旅时，他们倾向于按时间顺序缓解痛点。首先想到的是你最先完成的任务。对于应用程序的生命周期来说，那可能是创建服务。对于开发者来说，通常是新入职。许多组织选择首先从这里开始自动化。
- 易于展示：仪表板是您可以向您的管理者展示的东西，特别是如果他们没有技术背景。可视化要比重新构造配置管理更容易解释和销售。但这并不意味着它更有意义。
- 每个人都对界面有看法：尽管在平台工程领域，真正理解如何就底层技术和实际痛点（如配置管理）架构内部开发平台的人相对较少，但更多的人对界面有看法。结果是，关于界面的讨论比关于开发者体验中的真正深层问题更多。
为什么开发者门户和服务目录的努力常常失败？
在投入时间和资源开发开发者门户和服务目录之后，许多组织对结果感到失望。原因如下：
- 开发者讨厌“又一个界面”。他们希望留在代码中，在他们的 git-push 通道中，快速且不受干扰地操作。您可以构建最美观的用户界面，但这并不意味着有人会定期查看它。我查看了一个非常大的电子商务公司的门户的使用指标，发现平均来说，开发者每年确切地使用一次（搜索）功能，以检查他们正在构建的内容是否之前已经被构建过了。
- 可观的收益很低。我听到的最常见的用例是“我们想要标准化新服务的创建。”假设你每年创建了疯狂的 1000 个新微服务。你今天是如何做到的？可能只是通过克隆 GitHub 模板。因为门户本身基本上只是 UI 框架，它们所做的只是调用其他 API。所以如果你实现了“通过点击按钮创建新服务”的功能，这个按钮将调用 GitHub 模板 API 并克隆链接的示例仓库。使用最常用的开源框架构建一个门户，实际上需要至少两个全职员工 (FTEs) 至少六个月的时间。但你的影响在哪里？每次创建服务节省了 10 秒？即使是一分钟？我们假设由于某种奇迹般的原因是 1 分钟，我们拿 1000 个服务和我们每年支付 10 万美元的两个 FTE 来计算。那么你的投资回报率仍然在疯狂的 -80%，而且请记住这假设我们每年创建 1000 个服务！恭喜你，你只是浪费了时间。
- 门户和服务目录在实现和保持更新方面也是出了名的复杂。开发者会不断地绕过，一个数据错误的仪表板可能比没有仪表板更糟糕。你将花费大量的资源和时间尝试保持东西的最新。
将平台作为产品（Platform as a Product）来看待是一种方法
与其专注于构建开发者门户或服务目录，不如优先考虑对开发者最有益的功能。您可以通过采取产品方法来确定您的组织需要哪些功能。采用产品方法，您不会从构建"某些管理层"告诉您的东西或任何看起来显而易见的东西开始。相反，您要从用户研究开始。去问您的开发者他们需要什么或想要做什么。
然后，您有责任对这些问题进行排序。这样做的一种方法是记录开发者每 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* |
您可以使用这个表格来计算内部开发平台的投资回报率。 在大多数情况下，我发现两个变化产生了最大的结果：确保您真的建立了基本的 CI/CD 流程，可以减少辛苦工作并提高效率。将您的配置管理从“静态”重构为动态配置管理，可以通过设计实现标准化，关注点分离，并持续自助服务，同时降低认知负担。
什么时候您仍应该构建门户/服务目录？
这并不是说没有充分的理由来构建一个开发者门户。如果您的开发者正在创建大量的服务和资源，并且需要对它们进行分类以支持内部源代码共享的努力，那么门户会非常有益。然而，并不是很多组织拥有达到积极投资回报率所需的数千个服务和开发者。
有时候，你必须构建一个开发者门户，因为管理层这么要求。你别无选择。但如果这些情况都不适用于你，就不要浪费时间把开发者门户作为起点。相反，应该从构建你的内部开发平台(IDP)开始。你的开发者会感激你的！