内部开发者平台与门户的连接之道

一个内部开发者门户可以满足抽象和编排的需求。

译自 How Do the Internal Developer Platform and Portal Connect?，作者 Zohar Einy 是 Port 的 CEO，Port 是一个用于内部开发者门户的非代码平台，他与 Yonatan Boguslavski 共同创立了这个公司。

许多文章都解释了内部开发者平台和内部开发者门户的区别。区分两者固然重要，但更重要的是了解两者如何连接，因为坦白说，没有门户的平台不会让开发人员的生活更轻松。平台需要前端，而这就是内部开发者门户的作用。

让我们来看看平台是什么，门户与平台的关系，最后是平台和门户通过哪些 API 进行连接。

什么是内部开发者平台？

即使您没有意识到，您可能已经拥有了一个平台。内部开发者平台本质上是由您构建到软件开发生命周期 (SDLC) 中的所有内容组成的，包括您的基础设施、云以及介于两者之间的一切。平台是您已经拥有的所有平台工具和基础设施的总称。

平台是一个中心枢纽，由构建、部署和管理所有事物所需工具组成，其主要目标是改善开发人员体验。例如，平台提供对内部 API、微服务、SDK 和开发所需的其他资源的统一访问。它还提供集成的工具，例如 CLI 工具、构建自动化、CI/CD 流水线和基础设施配置。

这意味着开发人员无需直接在第三方工具（例如事件管理、应用安全或 FinOps）中工作。相反，开发人员通过平台访问这些工具。

内部开发者平台的主要目的是通过集中化资源并使其更容易访问来减轻开发者的认知负担。

那么为什么你需要门户和平台呢？

平台有助于抽象化复杂性，但并不足够。它们在可访问性、可扩展性和开发者所需的必要保障方面存在限制。对开发者来说，平台仍然可能很难理解，这意味着他们无法自给自足，这会影响他们花在解决问题、寻求帮助或创建 DevOps 工单上的时间。

内部开发者门户进一步抽象了复杂性，并促进了开发者的自助服务，同时提供了黄金路径并确保了相关的保障措施。

那么内部开发者门户具体做什么呢？

门户充当对平台的用户友好界面，通过提供一个单一用户界面来抽象化软件开发环境的复杂性，该界面专为不同开发团队的问题和需求而设计，使他们可以轻松理解整个技术堆栈及其导致的相互依赖关系。基本上，它们是为了提供更好的开发者体验和提高生产力而量身定制的。

门户将连接到您的平台，并执行以下操作：

• 摄取您的元数据并创建软件目录，为您提供所需的上下文。这将是您软件开发生命周期的全部所在之处 — 应用程序、服务、环境、资源 — 并且它将包含有关每个项目的所有信息，如所有者、文档和其他上下文。例如，软件目录可以包括来自 Kubernetes（K8s）的实时数据，以显示每个环境中部署的每个微服务的运行时信息。
• 门户通过一套自助服务操作驱动开发者的自治性。自助服务操作的主要优势是解放开发者免于重复、耗时的工作。平台工程师使用门户创建这些操作，并在其周围设置灵活的保护措施。这样，开发者可以在不需要帮助的情况下，提供新服务或获取云资源的临时权限。因此，这简化了工作流程并加快了开发过程。
• 门户确保开发者不仅仅是在“编写代码”，而是在推动组织标准和关键绩效指标。它促进了“左移”方法来解决安全、质量和运营问题。通过为开发者提供正确的见解（通过评分卡），门户帮助他们做出明智的决策，以交付不仅更快、更安全，而且质量更高的产品。

门户如何与平台交互？

如果平台是由用于软件开发生命周期（SDLC）的许多工具构成的，而门户是前端，那么我们现在需要定义它们连接的 API。当开发者在门户中执行自助服务操作时，它如何与底层平台进行通信？

这就是门户将用于触发平台特定操作的 API，从而实现自助服务操作，例如搭建微服务或配置云资源。这也是将用于创建软件目录的相同 API。

虽然有人认为门户需要一个中央 API（一个“编排器”）来连接平台，但我认为门户触发的 API 不止一个，而是多个 —— 平台现有工具和基础设施的现有 API。

平台 API 如何连接到门户呢？

让我们来看看这些平台 API。

CI/CD — 您可以使用现有的 CI/CD API，例如 GitHub actions，与门户连接，进行开发者自助服务操作。

GitOps 是另一个向门户公开的 API，通过执行 git 更改来执行操作通常被认为是最佳实践。通过从 git 中读取清单文件，并在门户内显示带有上下文的文件，您还可以丰富软件目录。

工程工具 — 整个开发工具栈也发挥着关键作用。每个开发工具都保存着与 SDLC 相关的信息，使开发者可以通过自助服务自行执行各种操作，并保持相关的见解。

功能标志是那些开发堆栈工具之一，应该被视为门户中的另一个 API，因为它可以使用户查看为每个正在运行的服务激活/停用的功能标志，连接到可观察性工具，如果检测到关键服务问题，则自动打开或关闭标志等等。

其他功能还包含与 SDLC 相关的相关信息：监控和可观察性、值班工具、应用程序和云安全、FinOps 和云成本管理、基础设施即代码（IaC）的使用、事故响应、权限管理、API 目录、工单工具、SaaS 管理等等。

IaC 是平台的另一个 API 端点，该 API 通常已经被开箱即用地公开。例如，您可以使用 Terraform cloud 或 Upbound 的 API 与您的平台进行交互。此外，将来自您的 IaC 执行运行的数据引入可以为门户提供与您想要让开发者了解的已提供、已终止或已修改资源相关的信息。

K8s — 与 K8s API 连接对于为开发者抽象 K8s 复杂性至关重要。通过将实时 K8s 数据与门户中的 SDLC 表示上下文相关联，软件目录变得更加完整和丰富。

最后，云服务提供商在平台中发挥着重要作用，主要是出于可观察性的原因。直接向开发者提供云控制台访问的不良做法显而易见。因此，我们希望在软件目录中可视化资源（在上下文中），然后通过从其他平台元素带来的其他数据来丰富它。

以下是使用内部开发者门户可以完成的不同操作示例：

• 声明将应用程序或功能发送到生产环境的过程，并确保开发者不偏离该过程
• 自动运行书
• 终止具有内置生存周期（用于临时环境用例）的资源
• 管理平台用户的权限
• 如果某一套要求未达到，则阻止将功能部署到生产环境
• 在需要经理批准的情况下执行运行书（因此还要跟踪手动批准）

编排发生在哪里？

到目前为止，我们已经描述了两个步骤：

1. 门户充当一个统一的界面，开发者可以在其中获取和找到他们所需的一切。换句话说，他们可以在其中“编排”开发者通过 SDLC 旅程的业务流程，一步一步地进行。这个工作流程 —— 包括检查拉取请求批准、显示合并、部署到暂存等 —— 在门户中定义，并在门户中“编排”。
2. 然后，门户通过各自的 API 触发平台工具来运行、调度和监控一个动作。

编排属于哪个部分可能并不明显。

门户最适合与各种平台 API 一起使用。这是因为它使用软件目录作为平台的唯一真相来源，可以整合日志、手动批准等。当开发者在 GitHub actions 或任何其他工具中执行自助服务操作时，门户还可以触发平台中的操作，这可以与平台工程师定义的黄金路径相一致。此外，它可以触发智能工作流程，其中一个示例是当开发者设置带有 TTL 的环境时。一个触发器设置它，然后一个工作流自动化流程（在门户中定义）将及时终止环境。

由于您可能已经拥有由现有 API 组成的平台 —— 并且因为大多数组织（根据 Gartner 的数据，75%）拥有平台工程团队将提供内部开发者门户 —— 这意味着更强大的方法是直接利用门户连接到 API，从而有效地使平台工具/编排器变得多余。

因此，门户与平台之间的 API 看起来如下图所示：

Zoom

门户提供简单性

平台工程旨在降低复杂性，提升开发者体验。选择门户来满足您的编排需求将在一定程度上实现这一目标。门户提供了一个统一的集成点，与您的其他所有工具相连接，简化了流程。相比之下，一个特定的平台编排器/工具需要在各个交叉点集成多个组件，为您的平台增加了另一层复杂性。如果您想要坚持您的平台工程原则，那么对于您的编排需求，您会使用哪种选项，这是一个明确的选择。