The ups and downs of using an internal developer platform

What is an internal developer platform?

An IDP is a collection of self-service tools and services development teams can use to configure and deploy application infrastructure without direct help from the operations team. This means developers can independently spin up environments for tasks such as automated testing and deployments as needed.

An organization's infrastructure, development, operational and automation requirements are key parts to make a viable IDP. To ensure everything stays on track (and simultaneously lighten their own workload) the operations team can configure the platform to align with governance and permissions requirements and automate otherwise repetitive deployment tasks.

A typical IDP supports a range of infrastructure and hosting options, such as on-premises, private cloud and public cloud deployment. On top of this, a platform management layer helps operations teams build and manage the IDP.

Another level up is a collection of services, tools and resources which are consumed by the application development teams. The services layer is made available through APIs or a combination of Git repositories and YAML files that make these services entirely declarative and defined as code.

Lastly, platform engineers in the customer organization build an interface for the IDP. Typically this is a command-line interface that supports basic commands to create new resources needed to run the apps they build. As the IDP process becomes more refined, engineers might build a user interface around the CLI.

The advantages of an IDP

An internal developer platform is essential especially in large organizations, but there must be a fair discussion about their pros and cons. Conduct a cost-benefit analysis of the effort required to set up and manage the platform, and the value derived from it thereafter.

Here is a list of major benefits of an IDP:

• Promotes automation. Internal developer platforms help ease the complexities of automation within organizations. Cumbersome processes, such as spinning up new environments and navigating complex deployment, become easier with automation.
• Quickens release cycles. Developers gain access to new environments and deployment pipelines, and can provision their own resources in a self-service manner. These environments are nurtured by the operations team, so they are already vetted and approved for use. This leads to fast, consistent and stable release cycles -- production-ready deployment environments created in minutes, versus days or weeks of a back-and-forth IT ticketing process.
• Enhances integration. An IDP integrates efficiently within an organization's existing workflows and infrastructure. It aligns the priorities of development and operations teams and ensures greater ownership at every step of the pipeline.
• Increases self-service. A key benefit of an IDP is that it allows developers to enjoy a self-service experience -- they have the entire deployment process at their disposal. Developers can request resources, control environment builds and set deployment automation in one place. This removes, or at least reduces, the need to raise support tickets and wait days for busy operations teams to process the request manually.
• Improves security. While a development team may not be overly concerned with security, operations teams usually compensate for this as gatekeepers and prevent many releases due to security concerns. An IDP gives operations teams peace of mind that they've created the post-development part of the pipeline according to their security standards. This means developers need not touch production environments and make changes, which drastically reduces human error when it comes to security.
• Well-defined project boundaries. When implementing an IDP in a large enterprise that has multiple development teams working together, the different teams should be able to work independently on their applications or services and not impede each other's work. An IDP helps to set boundaries in the form of unique Kubernetes cluster namespaces and approved resources for each team. This helps restrict teams to their own clusters and workflows and ensures optimal cross-team collaboration.

Potential downsides of an IDP

Unfortunately, the downsides of an IDP can potentially dampen its efficiency. Some of the biggest challenges associated with an IDP include:

• Adjustment to culture change. As with any major change in system architecture and operations, an IDP requires a change of culture. Operations teams must proactively create a variety of resources and templates for development teams to use, and update and secure these resources by default. Similarly, development teams must wean off raising tickets and instead look for the resources they need in the IDP.
• Increased management complexity. Although IDPs excel at managing complex processes and automating them to a great extent, they are by no means simple to create and manage. They require constant maintenance to ensure they are current, secure and able to evolve with the organization's needs.
• Risks of automation and autonomy. Automation is powerful, but also potentially dangerous. As developers gain access to deploy code immediately, they must also check bad code before it reaches users. This requires mature test automation and security checks before every release. Otherwise, automation and autonomy will backfire and magnify every issue as it progresses through the software delivery pipeline.