The ups and downs of using an internal developer platform
IDPs can provide a productive and secure environment for development teams. Consider the pros and cons to see if an internal developer platform is right for your organization.
Enterprises strive to deliver digital products faster through streamlined application development processes. However, the sheer number of infrastructure decisions associated with complex, enterprise-level software architectures can stymie this goal.
To get around this, organizations must lift the burden of operational decisions from development teams and allow them to focus on prototype builds and feature additions, rather than scaling and resource provisioning.
The answer to this problem may lie in an internal developer platform (IDP). Developers who need a new staging environment for secure cloud applications, for instance, can use an IDP's preapproved public cloud templates or spin up a test environment on demand without bothering the operations side.
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.