Internal Developer Platform

An internal developer platform, often abbreviated IDP, is the thing a platform team actually ships: a set of integrated capabilities, such as environments, pipelines, storage, credentials, and observability, that other teams in the organization obtain without assembling those pieces themselves. The platform team also commits to operating those capabilities, supporting their users, and evolving them.

Users reach those capabilities through interfaces such as portals, APIs, command-line tools, and project templates, which in turn rely on integrations with cloud and delivery systems. The interface is how the platform is used, not the platform itself: a portal whose buttons open tickets for manual work adds a front end without adding self-service. The supported entry points should share coherent concepts, defaults and permission rules. APIs and CLIs provide programmatic access without relying on browser automation. The interface choices should follow the tasks its users need to perform.

The CNCF platforms white paper describes a consistent experience across capabilities delivered through self-service. That can reduce users’ cognitive load by reducing the systems and integration details they must manage. An emerging platform may still rely on manual fulfillment. Assess which capabilities have a shared contract, which are self-service, and how long other requests take. Explicit review for unusual resource needs, sensitive data, or destructive changes can be part of the service contract; it should not be confused with an undocumented queue for routine work.

Scope and exceptions need deliberate choices. A narrow platform leaves more integration to users; a broad one adds maintenance and coordination work. A supported golden path can cover common tasks, with a documented process for needs it does not serve. That process should state applicable controls, approval requirements, and who supports an alternative. An unmet need may justify extending the platform, approving an exception, or declining the request.

Designing from assumptions about users can leave common tasks poorly supported. Running the platform as a product means observing those tasks, collecting feedback, and measuring whether changes improve them. Internal users can contribute this evidence through regular contact with the platform team.

Where a data platform fits alongside this, and which capabilities belong to which, is the subject of Data Platforms and Developer Platforms.

References

• CNCF TAG App Delivery, Platforms White Paper