Internal Developer Platform (IDP): Self-Service Delivery

Best Practice: Internal Developer Platform

An Internal Developer Platform (IDP) is the actual self-service product that platform engineering teams build and operate. Where platform engineering is the discipline, the IDP is the thing developers use: a set of integrated tools, APIs, and interfaces that let teams provision infrastructure, scaffold new services, deploy, and observe their applications without filing tickets or memorizing the entire toolchain. A good IDP exposes golden paths with sensible defaults and guardrails, hiding underlying complexity. The CNCF and the broader cloud native community provide reference architectures. During modernization, an IDP standardizes how teams build and migrate so the secure, compliant path is also the easiest.

Step-by-Step Implementation Guidance

Inventory the tools and steps a developer needs today to go from code to production.
Define the core capabilities the IDP should expose: provisioning, scaffolding, deployment, and observability.
Choose a developer interface: a portal (such as Backstage), CLI, or API, often all three.
Implement software templates and golden paths for common service types.
Integrate infrastructure as code and policy as code behind the self-service surface.
Provide a service catalog so developers can discover and own components.
Roll out incrementally, measure adoption, and iterate from feedback.

Common Mistakes Teams Make When Ignoring This Practice

Knowledge of how to ship locked in a few senior engineers' heads.
A portal that is a links page with no real self-service action.
Guardrails enforced by review meetings instead of automation.
Building everything custom instead of integrating existing tools.
No catalog, so service ownership and dependencies are unclear.

Tools and Techniques That Support This Practice

Backstage and other developer portals as the IDP surface.
Crossplane, Terraform, and Pulumi for self-service infrastructure.
Open Policy Agent and Kyverno for policy-as-code guardrails.
Argo CD or Flux for GitOps-based deployment.

How This Practice Applies to Different Migration Types

Cloud Migration: Offer one-click landing zones and environments so teams migrate onto governed infrastructure.
Database Migration: Expose self-service provisioning of target databases with migration runbooks built in.
SaaS Migration: Provide templated integration scaffolds so teams connect to SaaS consistently.
Codebase Migration: Scaffold target-stack services from golden templates so migrated code is compliant from day one.

Checklist

Core self-service capabilities are defined and available.
Developers use a portal, CLI, or API, not tickets.
Golden-path templates exist for common service types.
Guardrails are enforced through policy as code.
A service catalog tracks ownership and dependencies.
Adoption is measured and acted on.
The IDP integrates existing tools rather than rebuilding them.

Internal Developer Platform