Internal Developer Platforms (IDPs) are at the core of the platform engineering discipline.
The basic concepts are that an IDP:
- Should be thought of and managed like a product. This means that an IDP has a release cycle, a product owner and a product roadmap laying out which features are planned, a process for reporting and fixing bugs, and is developed with the clear focus of providing value to its users: software developers.
- Is built and maintained by platform engineers. As a relatively new job description, platform engineers often have previously held roles as DevOps engineers, system administrators or operations or deployment specialists. Platform engineers are responsible for the IDP as an internal product. While the areas of responsibility of platform engineers largely overlap with that of DevOps, the mindset is different: Platform Engineers are not a service team that “does stuff” for developers, but they are a product team that “builds stuff” for developers. (I know that a team that “does stuff” is not how “true DevOps” is supposed to work – but it is the bleak reality in the majority of companies that have DevOps as a role.)
- The IDPs core users are software developers
- Who use the platform in self-service
- IDPs provide features as so-called golden paths which developers can choose to follow, or choose to diverge from
- IDPs generally favour as-code approaches, for automation as well as (auto-generated) documentation.
IDPs provide features that are central to the daily work of software developers, such as:
- Documentation and information about components / software that the software developers in a company work on, such as:
- Which software / components exist
- What are they called
- How are they connected
- Which team owns which component and how can I get in touch with them,
- Links to documentation and the source code repositories associated with a component,
- etc.
- An overview of existing environments: what is deployed where in which version. For example, which test environments exist and which components in which version and which configuration are running there.
- Ability to interact with environments, such as
- Deploying new environments (feature branch environments, test or development environments etc.),
- Changing configurations of existing environments,
- Updating existing environments,
- Deleting environments,
- etc.
- Seeing the current status and possibly statistics about the CI/CD pipeline(s), such as
- which builds are currently running,
- which builds failed or succeeded in the past,
- whose commit triggered a build,
- etc.
- Documentation of things like
- Development best practices
- Tools and processes used for software development in the company
- etc.
These are just examples of features that an IDP can have. IDPs are always unique to the organisation that is using it. They are often hand-built from scratch, or heavily customised, using one or several of the platform products which are described in this whitepaper. Many companies may use something that could be called an IDP without even realising it (or calling it an IDP) – while other companies have a simple documentation platform which they call an IDP. Which is fine. IDPs are not a homogeneous product category, but rather a concept that is realised differently in each team and each company.
Through all of this, IDPs aim to solve the perennial crux that haunts all software developers: Software is hugely complex and no one person can know everything that is required to build an entire software product. But it is fiendishly difficult to sensibly divide responsibilities between development teams. Especially between development and operations teams, there are huge and complex dependencies which can lead to a lot of conflict and large inefficiencies. Many approaches have tried to address this, from
- agile teams that aim to contain a wide breadth of expertise within small team with minimum dependencies to other teams,
- the entire idea of micro-services which again aims to reduce dependencies between people and teams by allowing smallish teams to take care of one microservice independently,
- to devops, which also aims to bring development and operations closer together to remove friction and inefficiencies in the flow of information between them,
- to now the idea of platform engineering, which aims to separate out some aspects of operations and development tooling which are taken care of in a separate team, with a sufficiently flexible and yet standardised “interface” (the IDP) to development teams,
all with the goal to make specialisation and deep expertise possible by reducing the breadth of expertise required to do anything in software development.
In the end, IDPs are about reducing the complexity of software development.
This blog post explains well and a bit more extensively what platform engineering is and how it came to be: https://platformengineering.org/blog/what-is-platform-engineering
A disclaimer about platformengineering.org and internaldeveloperplatform.org
Platformengineering.org and internaldeveloperplatform.org are seemingly innocuous community websites which rank highly on Google on all topics related to IDPs and platform engineering. I reference them in this whitepaper on several occasions, since they do provide solid content on fundamental topics in this area.
But: Both of them are owned and operated (and quite shamelessly used as a marketing channel) by PlatCo GmbH, which is the company behind the Humanitec product suite. Humanitec is extremely dominant in shaping the vocabulary and discourse around platform engineering, and can be credited with introducing some of the fundamental concepts of platform engineering. While I do believe that they are genuinely passionate and definitely highly knowledgeable about platform engineering as a discipline, and the global community of platform engineers, it is important to be aware that this is also a commercial entity with commercial interests.
As such, both these websites mention Humanitec as a market leader, platform orchestration as a core component of any internal developer platform, and generally present the topic of platform engineering and IDPs in a way that serves the positioning of their products.
IDP: Internal Developer Platform or Internal Developer Portal?
IDP most commonly refers to Internal Developer Platform, however there is quite a bit of content out there that talks about Internal Developer Portals. So what is the difference?
Internal Developer Platform refers to the entire stack provided by the platform engineering team to developers, which typically consists of
- some kind of user interface – often called “portal – which can be a graphical user interface or web app and/or a command line interface (CLI) and/or API(s) through which developers use the IDP, as well as
- an orchestration component or a dedicated IDP backend which provides native automation in addition to orchestrating
- several additional services such as a CI/CD pipeline and infrastructure automation capabilities which power the services provided to developers via the interface(s).
Internal Developer Portal on the other hand refers to “only” the frontend or interface part of the internal developer platform. The portal is the component that allows developers to interact with and use the IDP. It most often has a graphical user interface, an API, and sometimes a CLI. Dedicated portal solutions are often frameworks that can be heavily customised and/or extended with custom plugins. Often, they provide functionality to input and display documentation, and often natively support links to other common developer tools like git repositories. A portal on its own however doesn’t have automation capabilities and also doesn’t orchestrate other services. It needs to be integrated with other tools in order to provide value.
How do internal developer platforms work?
Summary
IDPs are self-service platforms built by platform engineers to streamline software development by automating deployments, configurations, and environment management. They act as productized internal tools with structured workflows (golden paths) and as-code automation to reduce complexity.
Bottom line: IDPs reduce complexity and improve developer efficiency by bridging development and operations with standardized, flexible tooling.
