平台工程已经成为一种技术解决方案，以填补DevOps中缺失的许多空白。特别是，平台工程的主要好处是如何在规模上提高敏捷性并消除孤岛——尽管这是DevOps一直以来应该做的事情。
改善开发人员的体验是关键，因为这是提高敏捷性的主要途径。实际上，这意味着开发人员通过优化的平台工程（提供具有自动化基础设施操作的自助服务功能）可以完成他们的工作，而不必承担与管理运维相关的繁琐任务。
这对于在云原生环境中工作特别有用，这样开发人员就可以创建应用程序或完成拉取请求，而无需管理Kubernetes的巨大复杂性和其他相关任务，如安全性。
Gartner预计，到2026年，80%的软件工程组织将建立平台团队，作为应用程序交付的可重用服务、组件和工具的内部供应商。分析师预测，平台工程应该最终解决软件开发人员和运维人员合作的核心问题。
然而，平台工程中一个经常被忽视的关键要素仍然是实际的开发人员体验。这就是所谓的开发人员内部门户网站发挥作用的地方，它是工程平台之上的一个界面，将确保开发人员能够完成他们的工作，其学习曲线类似于使用无代码替代方案。
有了正确的门户，开发人员必须花一年多时间学习如何为Kubernetes创建应用程序和在Kubernete上部署应用程序的日子一去不复返了。相反，开发人员可以立即开始运用他们的才能开发软件，以敏捷开发实践的节奏实现直接的业务目标。
在过去几年中，许多组织在尝试采用平台工程的过程中都专注于平台本身。他们通常会设计CI/CD管道、云基础设施、实施TerraForm并设计Kubernetes基础设施。
然而，在许多情况下，让开发人员可以访问平台的尝试可能会陷入困境。
Port联合创始人兼首席执行官Zohar Einy表示：“开发人员需要以他们能够理解的方式使用不同的平台元素和类似产品的体验，因为他们不需要了解幕后的一切。”
但通过实施适当的平台工程，可以减轻开发者的认知负荷，帮助他们获得所需的一切。这可以通过作为内部开发人员门户的现成产品来实现。”
为什么开源可能不是解决方案
成功设计一个能够提供开发者真正需要的门户平台是一项重大工程成就。尽管存在开源产品，但它们需要大量的内部资源来设置和管理。
旅游服务提供商Luxury Escapes的首席软件架构师Eran Stiller表示，领先的开源开发者门户是Backstage。由Spotify的工程师开发的Backstage具有高度的可定制性和可扩展性，但它需要开发者花费大量时间来采用，“你还必须自己管理，这需要额外的时间和精力。”Stiller说。
最近几个月，Backstage还发现了一些主要漏洞，这些漏洞可能会带来安全风险。
另一方面，Stiller说，商业产品通常在功能和可扩展性方面受到限制。
他说：“如果该产品能满足你的需求，并能与你当前的技术堆栈和平台配合使用，那就太好了。但如果不能，它对你的好处可能会受到限制。一个提供高水平定制和开箱即用的可扩展性的商业平台具有巨大的潜力，可以帮助那些不想或不能花时间调整和托管自己的Backstage实现的开发团队。”
开发人员门户清单
根据Einy的说法，开发人员门户应提供的功能有：
——自助服务提供了开发灵活性，也保持了合规性。门户网站的自助服务功能应该扩展到微服务脚手架之外，以允许开发人员在软件目录中公开的任何资产上提供和执行第2天的操作。同时，门户应确保任何操作都符合策略，并允许对某些操作进行手动审批。
——入口和平台的松耦合。通过这种方式，平台工程团队可以自由地根据其规范构建底层平台，并让开发人员以他们通过开发人员门户了解的方式使用平台数据。
平台工程团队可以选择为CI/CD、IaC、软件架构和所有DevOps选择他们想要的流程。
解耦允许在保持开发人员体验一致的同时对底层平台进行更改。
——集成组织自身数据模型的能力。数据模型被引入到软件目录中，该目录是组织内开发和管理的基础设施和软件的可视层。
理想的软件目录应该显示围绕软件开发生命周期的整个生态系统。这些包括CI/CD流、开发人员环境、管道、部署和任何云，“跨所有（研究和开发）部署，从应用程序开发，甚至数据、安全、产品和研究，基本上每个与软件相关的团队。”
——开发者门户内的工作流自动化支柱，允许机器与其交互。在开发者门户内，机器可以使用Port的实时软件目录访问单个API。这为机器提供了上下文中作为其工作流的一部分所需的信息：CI作业失败、自动终止资源或基于软件目录数据运行CD流。
此外，机器可以订阅触发器，例如：资源生存时间达到零、Cron作业计时器已过，或实体的创建、修改或删除。你可以使用订阅来触发自动工作流或任务。
Einy说：“这也是因为软件目录充当通用软件目录，而不仅仅是为开发人员抽象信息。”
Stiller表示，这样的门户功能“对于现代软件开发团队来说是必不可少的，对于那些规模较大或为多个部署单元（如微服务）构建软件的团队来说尤其如此。”
架构师体验
Stiller说，在后单体时代，软件设计需求变得更加复杂，“开发团队也随之成长，开始分发编写的软件。”
“这导致了一个问题，多个团队不断相互踩脚，所以我们转向了面向服务的架构，后来转向了微服务。问题是分布式架构比单体架构更难掌握和维护，这带来了新的挑战。”
Stiller表示，在基于微服务的应用程序开发中，监督开发人员流程的架构师通常需要理解系统的工作原理，并提出以下问题：
——应用程序部署在哪里？
——当前正在运行哪个版本？
——哪个服务依赖于其他哪个服务？
——哪项服务对大多数客户错误负责？
“他们需要工具来帮助理解分布式复杂性，并将他们引向应该关注的方向。一个好的内部开发人员门户能够做到这一点，它允许构建一个包含应用程序的所有软件的目录，服务、部署管道、基础设施组件、云环境等。”
他说，一个好的门户网站可以让架构师在其目录上叠加其他信息，这些信息通常在其他系统中可用，但需要在一个位置统一组织。
“例如，可以添加一层信息，根据可观测性平台中可用的数据来说明每个服务的错误率。或者可以添加一层信息，根据源代码管理系统或CI/CD管道中的信息显示特定交叉依赖关系的版本。”
添加信息后，架构师可以添加规则并创建仪表板。
“例如，可以根据服务的错误率对其进行排名，并对那些不符合服务级别协议的服务发出警报，可以对那些尚未将依赖关系更新到最低要求版本的服务发出警告。能够做到这一点，并以可访问的方式向团队中的所有开发人员显示所有这些信息，是无价的。”