The modern approach to software delivery is based on cloud-native services and the DevOps culture, entailing software development in containers, and deployment as microservices and management using CI/CD workflows. For many organizations that have shifted from a monolithic architecture to microservices, it has become more complicated to configure the infrastructure.
现代软件交付方法基于云原生服务和 DevOps 文化，需要在容器中进行软件开发，并使用 CI/CD 工作流部署为微服务和管理。对于许多已从整体架构转向微服务的组织来说，配置基础结构变得更加复杂。
Internal developer platforms (IDPs) were designed to compartmentalize complexity and make life easier for the Devs and the Ops, while also improving the project implementation quality and business performance. What is an internal developer platform, how does it work, and what benefits do companies get from using such a platform? Read on to find out.
内部开发人员平台 （IDP） 旨在划分复杂性，使开发人员和运维人员的工作更轻松，同时提高项目实施质量和业务绩效。什么是内部开发人员平台，它是如何工作的，公司从使用这样的平台中获得什么好处？请继续阅读以找出答案。
什么是内部开发人员平台？
Internal developer platforms are becoming widespread as they help teams and entire organizations streamline processes and communication related to feature development by allowing team members to concentrate on what is critical to their roles.
内部开发人员平台正在变得普遍，因为它们允许团队成员专注于对其角色至关重要的事情，从而帮助团队和整个组织简化与功能开发相关的流程和沟通。
An internal developer platform is a layer that embraces technologies and tools the operations team prepares and sets up for further independent usage by a development team.
内部开发人员平台是一个层，其中包含运营团队为开发团队进一步独立使用而准备和设置的技术和工具。
An IDP provides the basis for all company tools, services, APIs and knowledge. This is internal tooling that gives more freedom and flexibility for software creation. The goal of the IDP is to ensure the pace of development and hide unnecessary infrastructure details from software engineers. In the internal developer platform concept, there are two parties involved: the Ops and the Devs.
IDP 为所有公司工具、服务、API 和知识提供了基础。这是内部工具，可为软件创建提供更多的自由度和灵活性。IDP 的目标是确保开发速度，并向软件工程师隐藏不必要的基础设施细节。在内部开发人员平台概念中，涉及两方：Ops 和 Devs。
The operations team focuses on infrastructure: they configure the internal platform, specify resources, govern permissions, optimize and automate repetitive tasks to provide an ideal environment for developers — one that is properly configured so that developer teams can work self-sufficiently, without relying on the Ops. Developers can be autonomous and make the most out of such internal platforms, including automated testing, deployment and consistent processes, thanks to the ready-to-use development environment prepared by the Ops.
运营团队专注于基础架构：他们配置内部平台、指定资源、管理权限、优化和自动化重复性任务，为开发人员提供理想的环境 — 一个正确配置的环境，以便开发人员团队可以自给自足地工作，而无需依赖运营。开发人员可以自主并充分利用这些内部平台，包括自动化测试、部署和一致的流程，这要归功于 Ops 准备的即用型开发环境。
It can be said that the IDP is an abstraction layer allowing developers to deploy the needed infrastructure automatically, and build and run applications independently. Companies can buy ready-to-use IDPs or build proprietary platforms for internal usage.
可以说，IDP 是一个抽象层，允许开发人员自动部署所需的基础设施，并独立构建和运行应用程序。公司可以购买即用型 IDP 或构建供内部使用的专有平台。
内部开发人员平台的优势
IDPs are incredibly useful and beneficial for organizations as they streamline projects and help improve the level of satisfaction of team members. How do they do it? In the following ways:
IDP 对组织非常有用和有益，因为它们简化了项目并有助于提高团队成员的满意度。他们是怎么做到的？通过以下方式：
- 运营团队充分利用高效的技术和工具;它的负载是平衡的，压力得到缓解，所有重复性任务都是自动化的，从而提高了团队的生产力。
- 开发团队不依赖于运维;它可以依靠现成的平台配置和流程自行管理部署和环境。这提高了生产力和可见性，减少了负载和交货时间，并增加了部署频率。它还提示开发人员发挥创造力并尝试内部配置。
- 该公司依靠预先安排的完美平台流程，这使其能够快速、轻松地启动项目。
- 客户以更低的价格更快地获得他们的项目;软件版本变得更加稳定，因为项目可以从一开始就开始，并依赖于内部平台的开箱即用流程和工作流程。
IDP运作原则
How does an internal developer platform work? It integrates into the existing workflows and CI/CD processes and minimizes decisions related to infrastructure; it powers self-contained builds and manages role-based access.
内部开发人员平台如何工作？它集成到现有的工作流和 CI/CD 流程中，并最大限度地减少与基础设施相关的决策;它支持独立构建并管理基于角色的访问。
Since the organization’s experts decide on the configuration of the specific platform, the tool stack and the code base, all internal platforms differ greatly. A typical internal developer platform consists of the following key components that are centered around an API:
由于组织的专家决定特定平台、工具堆栈和代码库的配置，因此所有内部平台都有很大差异。典型的内部开发人员平台由以下以 API 为中心的关键组件组成：
- 基础架构编排（由运维人员使用）
- 基于角色的操作管理（由运营部门使用）
- 应用程序配置管理（由运维人员使用）
- 部署管理（由开发人员使用）
- 环境管理（由开发人员使用）
Depending on the platform, a user interface or a command-line interface may be provided for the API. APIs integrate technologies and tools that are used by the team to minimize maintenance and security risks. External resources connect via resource drivers that can be performed as stand-alone services or Infrastructure as Code.
根据平台的不同，可以为 API 提供用户界面或命令行界面。API 集成了团队使用的技术和工具，以最大程度地降低维护和安全风险。外部资源通过可作为独立服务或基础结构即代码执行的资源驱动程序进行连接。
When configuring an internal developer platform, the operations team automates and streamlines repetitive processes by doing the following:
配置内部开发人员平台时，运营团队通过执行以下操作来自动化和简化重复流程：
- 它们提供启用请求和环境所需的资源。
- 他们构建应用程序配置模板。
- 它们将群集分配给环境类型。
- 他们管理权限。
- 他们管理服务级别协议。
As a result, developers can do the following at their own discretion, not involving the Ops:
因此，开发人员可以自行决定执行以下操作，而不涉及 Ops：
- 更改配置
- 部署和管理部署自动化
- 启动、推出和备份资源和环境
- 请求资源
With an internal developer platform, developers can code in IDEs they are used to and rely on the existing git-push-deploy-based processes (an IDP only adds some automation to them). They use the platform to deliver the code.
Let’s have a look at how developers work with an IDP step by step. They:
After that, the platform accepts configuration changes, creates a manifest, places required variables into the container and enables the environment.
借助内部开发人员平台，开发人员可以在他们习惯的 IDE 中编写代码，并依赖于现有的基于 git-push-deploy 的流程（IDP 只会为其添加一些自动化）。他们使用该平台来交付代码。
让我们逐步看一下开发人员如何使用 IDP。他们：
- 选择环境类型，该类型会自动确定平台针对每个特定状态使用的资源
- 选择工作负载
- 更改预先安排的配置
- 开始部署环境。
之后，平台接受配置更改，创建清单，将所需的变量放入容器中并启用环境。
何时使用内部开发人员平台有意义
Although an internal developer platform is very useful for many projects and in many situations, it may be excessive in some cases. We don’t recommend switching to an IDP unless necessary, to make the most of its true value.
尽管内部开发人员平台对于许多项目和许多情况下非常有用，但在某些情况下可能会过多。除非必要，否则我们不建议切换到 IDP，以充分利用其真实价值。
However, the following points may red-flag that an organization needs to migrate to an IDP:
但是，以下几点可能会发出组织需要迁移到 IDP 的危险信号：
- 它计划切换到微服务架构。
- 它有一个由十几名开发人员组成的团队，预计还会进一步扩大规模。
- 它缺乏适当的DevOps专业知识。
- DevOps 工程师处理太多重复性任务。
- 开发人员高度依赖操作人员。
- 它需要对基础结构进行全面、详细的访问。
- 它需要更好地控制平台的成本。
- 它有安全问题。
- 它规划多云应用程序。
In the following cases, the implementation of an internal developer platform would have a detrimental effect:
在以下情况下，内部开发人员平台的实现将产生不利影响：
- 由多达十几名开发人员和一些擅长基础架构配置和脚本编写的 DevOps 专家组成的小型团队
- 具有整体式体系结构或简单基础结构的应用程序
IDP 与 PaaS：谁赢得了这场战斗？
The core difference between the two types of platforms lies in the party that controls the technology stack and development processes. In the case of a platform as a service (PaaS), a vendor provides its prescriptions on this point, while an IDP allows teams to choose and set up internals they feel comfortable with.
两种平台之间的核心区别在于控制技术堆栈和开发过程的一方。在平台即服务 （PaaS） 的情况下，供应商在这一点上提供其处方，而 IDP 允许团队选择和设置他们觉得舒服的内部结构。
When should an organization choose a PaaS? If it’s small and needs to have an operational team as soon as possible. However, they should be prepared for little flexibility and freedom. In this case, Cloud Foundry, Heroku and other Platform-as-a-Service solutions are the workarounds.
组织应在何时选择 PaaS？如果规模较小，需要尽快组建运营团队。但是，他们应该为缺乏灵活性和自由做好准备。在这种情况下，Cloud Foundry，Heroku和其他平台即服务解决方案是解决方法。
When should an organization choose an IDP and not a PaaS? If it wants to have flexibility, freedom and complete control over its platform infrastructure and processes.
组织何时应选择 IDP 而不是 PaaS？如果它想要对其平台基础设施和流程具有灵活性、自由度和完全控制。
通过内部开发人员平台让开发人员和运维人员的生活更轻松
Internal developer platforms have become a widespread phenomenon, and are expected to gain even greater popularity in the future. Because of the incredible benefits that IDP provides to development and operations teams, many large enterprises, such as Airbnb and Spotify, use it extensively.
内部开发者平台已经成为一种普遍现象，预计未来会越来越受欢迎。由于 IDP 为开发和运营团队提供了令人难以置信的好处，许多大型企业，例如 Airbnb 和 Spotify ，广泛使用它。
摘自：
What Is an Internal Developer Platform (IDP)? | SaM Solutions
