Get Puppet Enterprise First 10 nodes are free!
Try it now
Request a demo
Automate IT and infrastructure, manage complex workflows, and mitigate risk at scale.
Try the full-featured Puppet Enterprise for free on 10 nodes.
Puppet Comply Find and prevent compliance failures
Compliance Enforcement Modules Remediate to stay in compliance
Continuous Delivery for Puppet Enterprise Build, test, and deploy infrastructure as code faster and easier
Content & Modules Pre-built scripts to automate common tasks
CentOS EOL Here’s how to secure your CentOS infrastructure – even after EOL.
Find thousands of component modules built by the community and guidance on using them in your own infrastructure.
Visit Puppet Forge >>
Open Source PuppetPerfect for individuals and small infrastructure
BoltAutomate tasks in orchestration workflows
See all open source projects >>
Contribute to open source projects >>
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.
Table of Contents
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 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.
A 2023 survey indicates the benefits of using an IDP include increasing development velocity, system reliability, better security, and standardization.
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:
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%.
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.
Download our free report for stats, definitions, and keys to platform engineering success.
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 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.
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.
The key components of an IDP are:
The key goals of an IDP, as described by teams doing platform engineering, include:
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
Download our free solution brief to find out how Puppet's ServiceNow integration makes key DevOps tasks faster, easier, and more reliable.
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.
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:
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.
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
Manager of Product Management, Puppet by Perforce
Margaret Lee is a product leader at Puppet by Perforce. She has always worked to give a voice to the Puppet user base, establishing her as an advocate for customer needs. She leverages her cross-team experience to identify the challenges Puppet customers face and find solutions that ensure DevOps success.