An internal developer platform (IDP) is a self-service layer between developers and infrastructure. It provides abstractions, automation, and interfaces for provisioning resources, deploying code, managing environments, and monitoring applications without requiring deep infrastructure knowledge. section 10.6.1
A practical IDP typically combines:
- Application configuration management for dynamic, scalable, reliable configuration. section 10.6.1
- Infrastructure orchestration and on-demand ephemeral environments. section 10.6.1
- Deployment management through continuous delivery or continuous deployment pipelines. section 10.6.1
- Templates, policies, and role-based access control that enforce consistency, compliance, and appropriate permissions. section 10.6.1
An IDP is operational and action-oriented: developers use it to deploy applications, provision resources, and manage environments. A developer portal is primarily an information and collaboration hub for documentation, APIs, tools, and shared knowledge. Combining both creates a unified interface that reduces context switching and cognitive load. section 10.6 section 10.6.3
Deploying a microservice through an IDP
A developer selects a service template, configures the application, and starts deployment through a self-service interface. The platform handles build, testing, provisioning, and deployment automatically, allowing the developer to focus on product features rather than infrastructure details. section 10.6.1
Table 10.1 Five key features of an IDP
| Key features |
Description |
| Application configuration management |
Manage application configuration in a dynamic, scalable, and reliable way |
| Infrastructure orchestration |
Orchestrate the infrastructure dynamically and intelligently |
| Environments |
Ephemeral environments on demand |
| Deployment management |
Implement a delivery pipeline for continuous delivery or even continuous deployment |
| Role-based access control |
Manage who can do what in a scalable way |
| Reproduced with permission from InternalDeveloperPlatforms.Org. | |
Use the feature table to inspect the core operational capabilities expected from an IDP. section 10.6.1
Table 10.3 Comparison of an IDP and a developer portal
| Criteria |
IDP |
Developer portal |
|---|---|---|
| Purpose |
Emphasizes operational aspects, enabling deployment and management of applications with ease and consistency |
Focuses on information dissemination and collaboration, providing access to resources and facilitating communication |
| Usage pattern |
Provides interfaces for performing actions such as deploying code, provisioning resources, and managing environments, directly affecting the development process |
Serves as an information hub, often read-centric, offering access to documentation, APIs, tools, and resources to support developers in planning and decision-making |
| Key capabilities |
Self-service deployment Automated provisioning Infrastructure abstraction CI/CD integration Environment management |
Centralized documentation API catalog Knowledge base Collaboration tools Project templates |
| Delivery workflow |
Directly streamlines and automates the development process, reducing manual tasks and speeding up deployment cycles |
Supports planning and decision-making |
| Developer workflow |
Directly affects the development workflow by automating repetitive tasks, enabling faster deployments, and managing application lifecycles |
Supports the developer workflow by providing the necessary information and context, aiding in planning, decision-making, and learning processes |
| Focus |
Operational efficiency and developer productivity are achieved by simplifying deployment, resource management, and infrastructure complexities |
Knowledge sharing, discoverability, and collaboration by centralizing documentation, APIs, and tools for developers |
| Organizational effects |
It offers actionability, allowing developers to deploy, configure, and manage applications effectively. |
It acts as an access point to the IDP’s capabilities, providing information and context about the actions available within the IDP. |
| Collaboration |
Supports collaboration through shared tooling for deployment and operations, allowing cross-functional teams to work well together |
Facilitates collaboration by providing a centralized clearing house for documentation, knowledge sharing, and communication among developers |
| Developer Experience |
Enhances the developer experience by reducing complexity and providing self-service capabilities, making it easier to manage applications and environments |
Enhances the developer experience by centralizing resources and reducing the effort needed to find information, promoting best practices and consistency |
| Integrations |
Often integrates with CI/CD pipelines, monitoring tools, and infrastructure providers to automate and streamline operations |
Integrates with various tools and platforms, such as source code repositories, API gateways, and project management systems, to provide a holistic view of available resources |
| Context switching |
Minimizes context switching by providing an integrated deployment and resource management platform |
Reduces context switching by serving as a single access point for documentation, tools, and resources, enhancing discoverability |
| Outcome |
Streamlined deployment processes, reduced infrastructure complexity, and accelerated delivery cycles |
Improved knowledge sharing, better documentation accessibility, and enhanced collaboration across teams |
| Example use cases |
A developer uses the IDP to deploy a new microservice, automatically provisioning the necessary infrastructure and setting up monitoring. |
A developer accesses the portal to find the API documentation and best practices for integrating a new feature into the microservice. |
| Example industry logos |
Humanitec, Mia-Platform, Kratix |
Backstage, Cortex, Port |
Use the comparison table to separate IDP actions from developer-portal information and collaboration functions. section 10.6.3
Treat an IDP as a product that evolves around developer needs rather than as a collection of tools. Integrate it with documentation, APIs, collaboration resources, automation, monitoring, and reliability practices, then measure delivery speed, reliability, developer satisfaction, and cost savings. section 10.7.1 section 10.8
