Is it best to build or buy your Internal Developer Platform?

The question of whether to buy or build an Internal Developer Platform (IDP) is a crucial one, especially for enterprises navigating the complex digital transformation landscape (the CNCF landscape is a pretty good proxy for the complexity here). What’s clear: a one-size-fits-all approach simply does not work. Most people miss this, but you just can’t buy an IDP. An IDP you can buy is actually called a Platform-as-a-Service, or PaaS. A PaaS is suitable for startups or small engineering organizations (less than 50 developers), working with a greenfield setup. However, if you find yourself in a brownfield enterprise setting, buying a PaaS solution comes along with huge limitations.

For this reason, large enterprises build their IDP using a combination of open-source, commercial, and in-house tools, instead of buying a PaaS. 

In this blog post, we’ll dive into what factors organizations should consider when deciding whether to build or buy and how organizations can unlock their IDP’s full potential with a Platform Orchestrator.

What is an Internal Developer Platform?

Let’s start by defining what an Internal Developer Platform is. According to internaldeveloperplatform.org, “an Internal Developer Platform (IDP) is built by a platform team… [and] consists of many different tech and tools, glued together in a way that lowers cognitive load on developers without abstracting away context and underlying technologies. Following best practices, platform teams treat their platform as a product.” 

McKinsey & Co recently spoke at PlatformCon about their research looking at hundreds of real-life platform setups, which uncovered common patterns in IDP architectures. They distilled these patterns into five architectural planes, differentiated by scope, as shown in the diagram above (this specific one is for an AWS setup, there are reference architectures for GCP and Azure too, with more coming soon). The most basic setups are made up of a Developer Control Plane, Integration and Delivery Plane, and Resource Plane. Monitoring and Security are pretty obvious and quick additions, especially in the enterprise. The reference architecture above is an example of how tools can be clustered into each plane. The combinations of tools that go into each plane of an IDP are flexible and adaptable to the needs of the organization. Swapping out one tool for another shouldn’t require replacing all of the tools in the same plane or the larger IDP.

The platform as a product approach is crucial to the success of an IDP. This involves conducting user research, soliciting regular feedback, iterating, and marketing it internally to your customers: the developers. This approach cultivates collaboration between the platform team and developers, improves feedback loops, and enables continuous improvement of the platform. It also ensures that your IDP best meets the specific needs of your organization. An important implication of a platform as a product approach is that successful IDPs have to be built (though not necessarily from scratch), not bought.

Thankfully, IDPs are worth the effort they take to build. By removing friction and bottlenecks from the software delivery process, IDPs improve developer experience (DevEx), boost developer productivity, reduce time to market (TTM), and increase revenue. According to a recent Forrester Opportunity Snapshot, 74% of DevOps leaders say that improving DevEx with an IDP boosts developer productivity, 77% that it can shorten TTM, and 85% that it drives revenue growth. 

What is a PaaS?

Platform as a service (PaaS) describes one tool that covers parts of CI, CD, environments, infrastructure, and interfaces for developers (UI or CLI). The feature set of a PaaS would span across several of the planes discussed above. Unlike an IDP, a PaaS can be bought. Organizations that buy a PaaS instead of building an IDP can enjoy lower upfront costs and time savings. However, this comes with some important limitations: lack of customization, vendor lock-in, and potential integration challenges with legacy technologies. As a result, brownfield enterprise setups find that a PaaS usually cannot integrate with their existing setup and skip it. However, for smaller startups with less than 50 developers, a PaaS can sometimes be more efficient than building an IDP in-house. What’s important is to have a migration plan, as your organization scales.

Why enterprises should build their own IDP

While buying a PaaS can seem tempting at first glance, enterprises inevitably find that building an IDP using a platform as a product approach is worth the extra effort. Here’s why:

Works with a brownfield setup. Most enterprises have a brownfield setup or a number of legacy systems they need to integrate into their platform. A PaaS is unlikely to be compatible with all existing systems, causing integration and security challenges.

More freedom and flexibility. Building an IDP enables organizations to tailor their platform to their specific needs. In contrast, a PaaS offers limited control over infrastructure and creates dependence on the provider’s capabilities.

Long-term cost savings. Though building an IDP can have higher initial costs, organizations that build instead of buy save in the long run by avoiding subscription fees.

No vendor lock-in. PaaS customers become locked into an approach and interface that can be quite difficult to migrate away from. When organizations build their own IDP, they can architect it in a way that allows them to swap out vendors of certain tools and preserve a greater degree of autonomy.

How to build your IDP the right way

Our 2023 DevOps Benchmarking Study ranked platform teams based on their performance on the four DORA metrics and platform engineering best practices. The study found that only low-performing teams built their IDPs entirely on their own. In contrast, top-performing teams leveraged a combination of open source and vendor tools (38.8%) or open source tools (41.8%).

The key takeaway is that winning platform teams don’t try to build everything from scratch. Instead, they leverage the right tools for the task at hand and tailor them to fit their organization’s needs.

One such tool is the Humanitec Platform Orchestrator. A Platform Orchestrator sits at the core of an IDP, driving standardization by design across all teams, and enabling true developer self-service. It lets teams generate new app and infra configuration files (e.g. Helm or Terraform), with every new deployment, following the golden paths designed by the platform team.

The Platform Orchestrator reads the developer request (e.g. a YAML file like Score or a CLI command), and it matches it to the rules set by the platform team. It then creates the required resources (e.g. Postgres in the example above) and deploys the workload. The Orchestrator easily integrates with any existing enterprise brownfield setup and can save enterprises months of trying to build the “glue” and orchestration layer on their own. See our build vs buy for the Platform Orchestrator to learn more.

Conclusion

For large-scale enterprises, building an IDP offers organizations substantial advantages over buying a PaaS, including the ability to tailor the IDP to specific requirements, foster innovation, reap long-term cost savings, and reduce time to market. For brownfield enterprise setups, building an IDP is necessary to properly integrate legacy systems and keep the flexibility required by medium and large organizations. Following best practices, enterprises also use a Platform Orchestrator as the core configuration engine of the IDP to drive standardization by design and enable true developer self-service.

Want to build an Internal Developer Platform but don’t know where to start? Check out these IDP reference architectures inspired by McKinsey’s research of hundreds of real-life platforms.