开发者门户和控制平面提供基础设施管理功能和一个易于使用的 UI，以推动自助服务操作。
译自 Drive Developer Self-Service with Crossplane, K8s and a Portal，作者 Mor Paz。
目前，许多工程组织都感受到了真正的痛苦：在运营方面，工程师们正试图疯狂地管理基础设施，与此同时，使用基础设施的应用程序开发者越来越多地被要求更多地了解基础设施，因此面临着认知超载。最终结果是什么？速度慢。
造成这种痛苦的原因是复杂性：首先，Kubernetes 作为云计算的实际操作系统出现，它需要大多数开发者根本不具备的深入技术知识，其次，开发者正在众多工具和框架的涌入中苦苦挣扎，而组织正在使用这些工具和框架。
为了解决这个问题，许多团队可能尝试使用 TicketOps 来 抽象并消除开发者需要掌握 基础设施。但是，这并不适用于第 2 天运营。虽然它最初可能会简化开发者的工作，但它可能导致运营团队成为瓶颈。
这是因为他们可能需要几天到几周的时间才能响应供应请求，因为他们需要确保请求符合安全要求、政策、版本问题等。
因此，运营仍然具有巨大的管理复杂性，并且开发者因此而延迟。归根结底，开发者只想开发功能并改进他们正在开发的产品，而 DevOps 工程师希望能够为他们提供一种无缝地执行此操作的方法。
是时候建立一个平台团队了
难怪 Gartner 认为，到 2026 年，80% 的工程组织将建立一个平台工程团队。这家分析公司认为，平台团队将作为可重复服务的一个内部提供商，为应用程序团队提供服务。换句话说，底层的内部开发者平台必须能够提供真正的开发者自助服务，以便开发者能够一次又一次地执行操作，而平台工程师能够设置护栏，以确保他们能够自主且安全地执行此操作。此类操作包括基础设施供应。
这就是内部开发者门户网站的用武之地。它充当一个单一的玻璃窗格，将构成内部开发者平台的所有工具汇集到一个地方。它提供了一个抽象视图，赋予开发者自主权，并为平台工程师提供一个地方，让他们可以在适当的标准下安全地向开发者公开功能和视图，以提高开发速度和开发者体验。
平台需要一个统一的控制平面
但是，平台工程师也希望对他们的平台有一个单一的控制和管理点，以便他们能够一致地应用策略、安全和其他控制。想想像 AWS 和 GCP 这样的云服务提供商能够向最终用户提供服务的方式，因为它们是围绕一个统一的控制平面设计的。这提供了易于使用的 API，同时为其自己的运营商自动化管理任务，以便他们能够支持这个庞大的平台。
这正是您希望在内部开发者平台的底层获得的------一个建立在云之上的统一控制平面。它应该使您能够一致地管理所有内容，并以 API 的形式向最终用户提供服务，他们可以直接使用这些 API 或使用这些 API 为强大的开发者门户界面提供支持。
平台的理想配方是一个内部开发者门户网站，它配备了一个软件目录，该目录利用 GitOps 来控制与受控制平面支持的云原生平台通信的 CD，该控制平面具有基础设施管理功能。
那么，平台和门户网站如何协同工作来公开对开发者和平台工程师都有益的自助服务功能呢？
在这里，我们探讨了将 Port 用于您的门户网站需求以及由 Crossplane 支持的 Upbound 用于您的控制平面需求。
控制平面
首先，我们可以查看 Upbound 控制台，它向我们展示了由 Upbound 管理的控制平面。我可以查看我的控制平面是否已准备就绪，以及有关控制平面使用的配置、版本和 AWS 提供商的详细信息，以直接与我的 AWS 云帐户进行交互。这是 Upbound 的设置，Upbound 将通过配置和管理云提供商托管的资源在后台完成繁重的工作。
但对于开发人员来说，这些信息并不是必需的。他们不需要了解有关控制平面和 Kubernetes 的详细信息------他们只需要一个简单易懂的 UI，以便他们可以看到自己的资源。内部开发人员门户提供了此抽象 UI，并且还可以使平台工程团队受益。
在主页上，平台工程师将能够看到请求新集群的操作。在触发该操作之前，他们可以查看软件目录中已有的内容，包括他们的 Upbound 控制平面以及有关它的更多详细信息，包括它管理的所有集群和它拥有的所有集群请求。
问题是：为什么它拥有所有这些集群和集群请求？
为了回答这个问题，我们可以查看"builder"部分，向您展示 Port 后端的工作原理。这是平台工程师用来配置开发人员使用门户的方式。
您可以在上面看到三个蓝图。蓝图是一个完全可配置的数据对象，一个模式，您可以对其进行建模以适合您想要表示的资产。因此，这里有三个蓝图：Upbound 控制平面、Amazon Elastic Kubernetes Service (EKS) 集群和 EKS 集群请求。
如果我们关注用户请求一个新的 EKS 集群，我们可以考虑为此进行一些自助服务操作。
首先，我们将了解创建新集群的两种不同方法。
新建集群：选项 1
第一种方法适用于想要创建新集群的平台工程师。他们只需转到自助服务中心并单击"创建新集群"操作。然后，他们将选择自己的控制平面，并输入所有输入（名称、节点大小、节点配置）。此表单可以由平台工程师完全配置。这意味着：
- 它将使开发人员的生活更轻松，因为他们不必考虑输入。
- 平台工程师可以通过设置护栏来确保操作安全并符合政策和标准，例如验证开发人员只能输入合法值。
一旦工程师填写完表单，他们就可以单击执行，Port 将创建一个新的自助服务操作。此自助服务操作将启动 GitHub 工作流，该工作流将为新集群打开一个拉取请求。
在这种情况下，由于管理此操作的是平台工程师------并且他们已经设置了所有输入和工作流------自助服务操作将自动创建该拉取请求并立即将其合并。这将同时显示在门户中和 Upbound 中的新集群中。记住这个新集群，因为我们稍后会回来检查它的进度。
新建集群：选项 2
开发人员可能需要一个新集群，因为他们正在开发一个新功能。他们可能需要诸如容器之类的资源来运行数据库或缓存，并且他们希望自己的应用程序与之一起运行。如果平台工程师公开了请求新集群的操作，则开发人员可以导航到自助服务中心并单击"请求新集群"。他们可以再次填写表单，并将节点大小和节点计数等输入保留为默认值，因为它们对开发人员来说可能意义不大。如果需要，平台工程师可以在以后解决此问题。然后，他们可以单击执行，平台工程师将请求并审查集群，如我们在下一部分中所见。
EKS 集群请求
继续进行 EKS 集群请求。这是平台工程师跟踪他或她对资源的所有请求的一种方式。这可以修改为 Upbound 可以为您管理的任何类型的云资源，因此它不仅限于 EKS 集群。
此页面的视图可以扩展和自定义，以便它可以同时为平台工程师和开发人员服务。
创建新请求时，它将使用两个关键组件执行。第一个是新资源的拉取请求------在本例中，是 EKS 集群。
第二个组件是我们在此处看到的这个新的集群请求，其状态为挂起。
作为一名开发人员，这可以帮助您了解最新情况并了解您的请求发生了什么，以及在批准请求并触发自动配置步骤之前是否仍在等待某些内容。
作为一名平台工程师，您可以看到哪些请求正在等待批准，并决定是否应该批准它们。
现在，如果我们查看之前的集群，我们已经可以看到一些资源开始达到就绪状态，这意味着我们将在几分钟内拥有一个新集群。一旦开发人员得知他们的请求已获批准，他们就知道在 10 到 15 分钟内他们将拥有一个正在运行的集群，并且能够开始处理他们的新功能。
个性化视图
当所有这些信息都存在于软件目录中时，工程师、经理和开发人员都可以使用它。
以下是服务仪表板，它显示了门户中拥有的服务（主要是 GitHub 存储库和微服务）。您可以看到，我在这里添加了一些信息：右侧显示了我拥有的 EKS 集群数量，该数量直接取自我们已部署并通过 Upbound 管理的 EKS 集群。
记分卡
为了更进一步，我还配置了 EKS 集群蓝图上的几个记分卡。这使我能够创建一个 EKS 就绪仪表板，向我展示我的所有集群以及它们如何根据组织配置的标准执行。在此示例中，两个集群处于青铜标准，一个处于白银标准，因此我可以看出哪些集群正在失败以及集群出了什么问题，并且我可以了解如何提高它们的排名以确保它们全部达到标准并做好生产准备。
内部开发人员门户与控制平面相结合，可以帮助您轻松管理基础设施，并且易于使用的 UI 可以共同推动开发人员自助服务操作。
这种组合可以实现：
- 平台工程师、开发人员和经理可以更好地查看对他们重要的事项。
- 减少开发人员的认知负担和平台工程师的时间。
- 克服复杂性。
- 提高开发人员效率并为他们提供更高的可见性。
- 更好的开发人员体验。
在此处了解有关创建自助服务操作的更多信息网络研讨会。
通过更好的开发人员体验，查看我们关于改进开发人员工作流的博客。 [