本文来自微信公众号“开源云中文社区”。
不管你喜不喜欢，你已经有了一个内部开发人员平台，即使你的组织从未建立过一个平台，也没有“平台工程”人员。它可能不是正确的平台，可能难以扩展或使用，但它确实存在。
这意味着你可能不需要构建平台；你只需要让它更好。你面临的真正问题是，是否应该在平台之上使用内部开发人员门户，因为它是平台工程堆栈中最成熟的元素。
我们在这篇文章中要讨论的是，门户很重要，它们也会影响平台工作的质量和有用性，随着它们和技术的发展，它们基本上会成为平台的一部分。
但是等等！内部开发者平台？内部开发者门户？有什么区别？为什么要在另一个之上使用一个？让我们首先定义两者，并就这将带我们走向何方提出一些大胆的论点。
什么是内部开发人员平台？
让我们从基础知识开始。平台是帮助工程师完成工作的工具。它可以让他们编码，留在区域内，不必太担心他们无法控制或没有专业知识的运维问题。
现代架构是复杂的，由许多底层技术和数百个微服务组成，软件开发生命周期对于任何人来说都变得太长了，需要太多运维和开发方面的专业知识。
解决方案是抽象掉一些复杂性，并创建一个统一的开发人员体验，这将减少开发人员和运维人员的认知负荷。这些更好的开发人员体验将提高生产力。这就是平台的意义所在。
受Gartner启发，分类的定义是，平台是关于自助服务功能和具有自动化基础设施运维的可重用工具。该平台由平台工程师构建，使开发人员从“粘合工作”中解放出来，并为开发人员制定标准和黄金路径。
所有这些都可以归结为开发人员自助服务。你不必构建自己的临时云环境，也不必执行第二天的运维，不需要DevOps的人来做，只需访问一个界面并获得所需的内容。想象一个Jenkins自助表单或Terraform无代码。
当然，这并不完美。例如，使用Jenkins进行自助服务意味着缺乏上下文和状态，用户界面扁平，无法设置组织标准（工程质量可以而且应该是良好的门户/平台工作的结果）。它也没有解耦。如果你改变了Jenkins，你也需要改变开发者的体验。这不太管用。
该平台的另一部分是为开发人员提供底层基础设施的某种程度的透明度，以便他们能够做出明智的决定。为了提高生产力而将所有内容都抽象出来在纸面上听起来不错，但需要显示一些数据，从依赖关系到Kubernetes设置、内存或CPU使用情况等。
如果没有一些数据，你就无法做到“建造它，拥有它”。一个很好的例子是GitOps（它可能构成现有平台的核心）。纯粹的GitOps对开发人员来说不太好，因为它包含了太多的信息，并且为开发人员提供了太多自由漫游和犯错的空间。在这种情况下，用一个平台替换GitOps或在其上添加一些平台元素可能会奏效。
什么是内部开发人员门户？
门户是平台的界面，帮助用户访问底层的异构软件开发生命周期资源，并使用门户中提供的自助服务。门户为开发人员和运维人员创造了类似的体验，因此每个人都可以自助服务，并获得对基础设施的适当可见性，从而做出正确的决策。这些体验类似于产品，旨在提供简单的黄金路径自助服务，以及执行质量标准，提高工程质量。否则，生产力就无法实现。
自助服务
开发人员在开发人员门户中使用自助服务。行动越多越好。首先，开发人员不仅需要构建微服务；他们需要许多第二天的运维，以及权限请求（TTL或生存时间）、设置临时环境等。一个好的自助服务体验应该尽可能像产品一样，帮助开发人员轻松地工作，在黄金路径内，并尽可能少地出错。这样做时，软件目录会通知开发人员，但自助服务操作本身需要立即反映在目录中。
内部开发人员门户是否“只是开发人员自助服务的UI”？不是。为了理解原因，让我们检查一下软件目录，然后解释它如何演变成平台API。
软件目录是一切的中心
软件目录通常被描述为包含微服务、云资源和基础设施的目录，显示上下文中的所有元素。它显示并可以帮助管理权限、临时环境和几乎所有其他内容。它包含了你可以驱动到其中的所有元数据。它将被抽象出来供开发人员使用，只向他们显示需要的内容。
然而，即使你可能正在抽象其中的内容，软件目录仍然充当通用元数据存储。因此，你可以对其运行任何查询并获得所需的答案，即使是对于被认为复杂的问题，如包漏洞计划。这是运维人员开始对软件目录感到兴奋的地方。
软件目录需要在一开始就足够中立，这样你就可以构建它以适合所拥有的任何数据模型，从而创建一个符合组织正在构建的任何内容的有见解的软件目录。
中央目录不仅仅是关于其中的所有数据，或者它对开发人员和运维人员都有什么用处。使用记分卡，目录还反映了特定实体（例如在给定环境中运行的特定服务）上下文中的质量、健康状况和其他度量。这有助于在有许多微服务、存储库和区域的环境中优先采取行动并提高质量。它也有助于通过在一个中心位置确定质量来改变组织行为。
软件目录也适用于机器和运维
你可能已经注意到，作为一个通用的元数据存储，我们谈论的是一个超越开发人员体验的软件目录。换言之，尽管名称如此，内部开发人员门户中的目录也是为机器和管理机器的运维人员创建的。
事实上，与我们交谈的许多运维人员都希望自己开始使用门户，以管理软件和系统的扩展。他们抱怨混乱的微服务跟踪和太多的DevOps工具，抱怨需要集中控制的复杂AppSec问题。然后他们明白了：他们想根据软件目录运行工作流。
这是工作流自动化，工作流检查软件目录中所有内容的状态。我们经常听到这样的消息，情况是这样的：“如果软件目录包含有关服务锁定/包/版本等的所有信息，我可以让CI工作流作为工作流的一部分检查软件目录吗？”
如果服务被锁定，工作流自动化将在目录中检查它，并且不允许它部署。如果服务运行状况关闭，则将采取另一项操作。在这方面，前面提到的记分卡是有价值的，因为自动化可以并且确实可以检查记分卡信息，作为其流程的一部分。
门户的核心原则
让我们了解一下内部开发人员门户背后的核心思想：
——自带数据模型。软件目录应支持常见的数据模型（如后台C4模型），以及唯一的数据模型。它应该足够中立，这样你就可以在其中建立一个自己觉得好的数据模型。
——软件目录应包含所需的所有数据，作为软件和资源的通用元数据存储。开发人员可以将数据抽象出来，但数据将保留在目录中，供其他用户使用，例如运维团队或工作流自动化。
——产品般的体验。UI应该为开发人员提供黄金路径体验。产品思维是内部开发人员门户的核心，UI应该是可配置的，支持无代码创建来支持这一点。
——与底层基础设施和自动化松散耦合。平台一直在发展，无论它们是随时间随意构建的还是新技术堆栈的结果。因此，内部开发人员平台（IDP）应该与它们松散耦合。如果底层云资源、CI或CD系统被替换，开发人员应该具有相同的体验。
——以最广泛的方式允许开发人员自助服务。为了确保采用，开发人员需要在IDP中满足他们的所有需求。只关注一个自助服务行动，平台进度和IDP都不会增长。
——API优先。
——设计符合要求且安全。
未来是平台API
开发人员门户的未来是成为一个平台API，为与平台交互提供统一的接口。开发者门户还将托管软件目录，为平台状态提供上下文，并负责触发平台自动化，作为其自助运维的一部分。开发人员门户将使用平台API作为前端接口，平台内部组件将使用该API根据存储在API中的上下文信息进行自动决策。
要进行平台工程，需要从门户开始
无论你是否同意你已经拥有一个平台，内部开发人员门户可能是可以开始使用的加入平台工程运动的最成熟和定义最明确的元素。内部开发人员门户非常有价值，足以推动开发人员生产力的显著提高，并为运维人员带来秩序。
