What an Internal Developer Platform (IDP) Is + Why You Should Have a Self Service Platform for Developers

An IDP, or internal developer platform, is a collection of IT tools that an organization structures to help developers self-service IT tasks. The concept of self service platforms for developers isn’t new to anyone who’s been doing DevOps for the last couple decades, but it's been thrust into the limelight with the recent surge of interest in platform engineering.

In this blog, we’ll tackle questions like "What is an IDP?", provide an IDP meaning as it currently exists, dig deeper why everyone’s talking about self service platforms, and show you how to start building an IDP.

What is a Developer Platform? What is an Internal Developer Platform (IDP)?

An internal developer platform (IDP) or developer platform is a collection of tools and tech that enable developer self-service (like configuration, deployment, provisioning, and rollback).

An IDP can be built by DevOps teams and/or dedicated platform engineers. In software development and IT, developers commonly use an IDP to spin up development servers and environments pre-configured with middleware and database resources. That increases efficiency by taking the task off the IT and infrastructure teams without skimping on security.

What's an Internal Developer Portal vs. an Internal Developer Platform?

An internal developer portal is the actual interface a developer uses to access the tools in a platform. The terms "platform" and "portal" are sometimes used interchangeably in platform engineering.

Confusingly enough, the abbreviation "IDP" can stand for either "internal developer platform" or "internal developer portal," depending on who you ask. Some platform engineering organizations might use the terms interchangeably, while others insist they're two separate things. Most can agree that they're both essential to platform engineering.

When the distinction is drawn, the difference between a platform and a portal is that a platform is the collection of tools, while the portal is the actual interface a developer uses to access the platform. The design of an internal developer portal usually gives users observability, templates, and reporting that streamline onboarding to the platform.

What Does an Internal Developer Platform (IDP) Do? 

An IDP structures development toolchains and workflows to let developers focus on development (instead of infrastructure and IT).

Developers want to spend time delivering valuable features to their customers – not making sure the underlying infrastructure meets their company’s standards. They want to focus on the app they’re developing, or the big new solution they’re working on.

They can’t do that when they’re wrestling with disparate tools that might not be tailored to their needs. Internal developer platforms can reduce the toil developers get mired in when they have to wrangle with their toolkit. When you hear the phrase “cognitive load” in reference to development, that's what it means.

An IDP also gives developers the tools they need to develop successfully. With a platform of tools ready to use, they don’t need to reinvent the wheel every time they build something. Platform engineering gives the development team a common set of tools to start with and build on top of. That reduces bottlenecks for developers and helps them deliver value to their customers quicker – which is a win for both the company and its customers.

Benefits of an Internal Developer Platform + Self Service Platforms for Developers

A 2023 survey indicates the benefits of using an IDP include increasing development velocity, system reliability, better security, and standardization.

An IDP Improves DevOps KPIs

The benefits of having an IDP are twofold. First, it delivers on common KPIs you’d typically associate with IT and infrastructure management. Responses to the 2023 State of Platform Engineering shed a little more light on specific ways an IDP has improved their DevOps KPIs:

• An increase in development velocity (68%)
• 42% say development velocity has improved “a great deal” since they started doing platform engineering
• Improved productivity (59%)
• Improved system reliability (60%)
• Improved security (55%)

The effect platform engineering and the use of an IDP has on DevOps KPIs also leads to greater satisfaction. 37% of firms doing platform engineering report being “very satisfied” with the efficiency of their product delivery process. At firms not doing platform engineering, that satisfaction rate drops to just 20%.

An IDP Provides Standardization Across the Whole Organization

Building an IDP forces organizations to standardize, which is helpful to many other teams within it.

Platform engineering teams say platform engineering and IDPs serve the needs of the entire company – not just a single department.

Because an IDP is created from feedback and interviews with many members of the organization, the whole organization (developers included) know it already has everything they need covered.

Security, for example, can know the standards they set for the IDP will apply in any app a developer is working on. For the developer, it reduces overall cognitive load since they don’t need to focus on all of the things that go into maintaining the infrastructure underneath their app (like security standards). They can just use the IDP and build on top of it.

The More You Use an IDP, the More It Works

The longer a platform team is around, and the more an organization invests in it, the greater the benefit to the people who use an IDP. We asked teams who’ve been doing platform engineering for more than three years (49%) and those who’ve been doing it for less than three years (51%) how they felt platform engineering and the use of an IDP was working so far.

Who Actually Builds Self Service Platforms for Developers?

Platform engineering teams build self-service IDPs. The platform team is made up of internal developers and product managers that are tightly integrated with the existing development teams.

Here’s how it works: Platform engineers talk to the people likely to use the platform, like developers, to find out exactly what will make their job easier. Then, they select the tools and workflows to match. That helps define the platform’s capabilities, with the intent to create those golden paths and reduce cognitive load on developers.

The most successful IDPs have a product manager and treat the IDP as a product. The initial set of requirements is usually pretty straightforward and consists of basic functions and baseline capabilities. Once those are addressed, the product manager can help discover and drive the next most valuable things for the IDP team to tackle.

Components of an Internal Developer Platform

The key components of an IDP are:

• Workflow automation tools
• Infrastructure building and management tools
• Deployment tools
• Security and compliance standards
• Testing capabilities
• Production application monitoring

The key goals of an IDP, as described by teams doing platform engineering, include:

• Automation of routine tasks and duplicate work. Making automation available to other development teams reduces rework and gets more of the common and routine stuff done quicker.
• Problem solving. If you find a solution to a common problem and bake it into a platform used by multiple development teams, it solves that problem for all those teams at once.
• Scaling. Scaling DevOps comes with plenty of challenges and benefits, but it’s only possible if you can automate once for multiple teams.
• Freeing up engineering so they’re not taking on too much extra work (which compounds problems across teams).
• Controlling infrastructure spending. An IDP allows organizations to limit infrastructure spending and find more opportunities to consolidate with one platform.

Internal Developer Platform Examples in DevOps

Internal developer platform examples include ones used by Google, Amazon, Spotify, Netflix, Twitter/X, Walmart, GitHub, and more. These large companies use their IDPs to boost productivity and improve the developer experience.

IDPs can start organically (from the bottom up) or from a top-down approach. In the former, a development team might recognize a problem, like duplicative work, DevOps hangups, and cognitive load. If it comes from the top down, CIOs and business leaders may be looking for new ways to increase efficiency and productivity by structuring their tools in an IDP.

Either way, successful IDPs are made in collaboration with other development teams. That helps the platform team understand the problems developers face and how an IDP can add value.

Want Great Self-Service? It Starts with Great Automation.

Download our free solution brief to find out how Puppet's ServiceNow integration makes key DevOps tasks faster, easier, and more reliable.

DOWNLOAD BRIEF

For example, imagine multiple development teams in an organization spend a lot of time standing up infrastructure. They notice it takes a lot of time to stand up that infrastructure (every time) before they can begin building their app on top of it. With an IDP, they can use an infrastructure automation tool to automatically stand up new infrastructure when they need it, while making sure it meets the proper security and compliance standards.

But it wouldn't be an IDP if it just automated infrastructure provisioning and configuration. Platform teams could pair that infrastructure automation with a ticketing system and also a place to push data out to so other departments can use the information as needed. The platform team could take it even further by bringing in other tools that help with testing and delivery to streamline the development process.

By setting up these tools before development teams even need to touch them, it speeds up development and time to release for the applications. The goal is to reduce cognitive load across the teams and help teams and the company be more cost effective and have a quicker time to value – for not only end user customers, but for internal customers. That’s when a set of tools becomes an IDP.

Do You Need an Internal Developer Platform?

Realistically, any team that regularly interacts with delivering code can benefit from an IDP. But because you need buy-in from internal stakeholders like business leaders and developers themselves, a platform is usually most useful for larger organizations and teams.

Organizations that might find the most value in building and maintaining an IDP include:

• Organizations with large, structured teams
• Organizations in industries like technology, financial services, and government

On the flip side, a platform engineering approach won’t be as useful for smaller teams with a small range of capabilities and tools. Organizations that can’t (or won’t) dedicate resources to it aren't ideal candidates for using an IDP, since a platform engineering approach needs ongoing investment in order to be successful.

Where Automation Fits in an Internal Developer Platform

Like DevOps, platform engineering can’t exist without some degree of automation. Automation lays the brickwork of golden paths for developers, and it’s essential to an IDP and platform engineering at large.

📖 Related read (10 min.): The real difference between platform engineering and DevOps

An IDP without automation will become a huge bottleneck for other teams. Automating the routine tasks that teams have to do, and making them available to developers via self-service, is a huge value driver for companies and has lasting benefits. Instead of doing something many times across multiple teams, you’re bringing it into a centralized location. That makes it easier to standardize across the organization and drive more value for customers.

That's what makes an infrastructure automation solution like Puppet crucial for building and managing infrastructure for an IDP. Puppet can make sure that all your infrastructure is set up in exactly the way your organization wants, all security and compliance standards enforced, and remains in your desired state on an ongoing basis. It also makes it really easy to add more infrastructure as your company grows, which gives you peace of mind that your infrastructure is consistent across your entire organization.

For more on platform engineering, download Puppet’s State of Platform Engineering Report (a special edition of the State of DevOps Report).

DOWNLOAD THE PLATFORM ENGINEERING REPORT