Internal Developer Platform Open Source

In today’s engineering landscape, many organizations are exploring the adoption of an internal developer platform (IDP). Based on its core definition, an IDP is used by a platform team to build golden paths and enable developer self-service. An IDP consists of many different technologies and tools glued together in a way that lowers the cognitive load on developers without abstracting away context.

The burning question is: “Can you use one or more open-source tools to build an IDP platform?”

In this article, we explore the contrasting options of procuring versus constructing an IDP. We delve into the core components of an IDP, offering insights into both their open-source and commercial incarnations.

By the end, you’ll be equipped with the knowledge needed to make a well-informed decision aligned with your objectives. Let’s dive right in, ensuring that we’re not merely slapping a new label on an old machinery.

Summary of internal developer platform open source concepts

The five core components of an IDP

Imagine a platform engineer immersed in maintaining a complex infrastructure on one of the major clouds, overseeing multiple Kubernetes clusters and managing hundreds of microservices deployed with Jenkins and ArgoCD. Driven by his ambition to optimize and streamline these processes, he stumbles upon the concept of an internal developer platform (IDP) at KubeCon.

Intrigued, he conducts research, seeking an open-source solution that seamlessly integrates into his existing stack. However, this endeavor proves to be more intricate than he initially expected.

He finds that an IDP is typically composed of five key components. These components are essential in developing a comprehensive set of templates that cover the golden paths of various development teams.

Once the platform team combines the five core components, it often needs to give developers a single interface to find, observe, and use templates from those components in their golden paths. That’s where developer portals and service catalogs step in. We will review them later on.

Each component is vital for orchestrating development processes and ensuring the seamless integration, deployment, and management of applications. In an open-source context, the challenge lies in finding tools that cohesively bring together these elements.

IDP is not a one-size-fits-all solution

The journey to an optimal IDP is not the pursuit of a universal solution but rather a tailored combination of open-source and commercial elements. For the platform engineer, this involves a strategic selection of tools that align with specific infrastructure requirements.

Balancing the versatility of open-source with the reliability of commercial products is the key to constructing a customized IDP. This bespoke approach ensures that the IDP aligns perfectly with organizational needs, maximizing developer productivity and operational effectiveness within the unique ecosystem of the existing infrastructure.

The IDP assembly line

Before diving into development, it’s vital to use product management strategies to analyze the developers’ workflows. This step is key to identifying areas where the team faces the most significant cognitive challenges, guiding the IDP’s design to address these specific issues.

Paved roads and golden paths

In the world of platform engineering, “paved roads” and “golden paths” are metaphors for streamlined, well-documented processes that make development work more efficient and less error-prone. By reducing the cognitive load on developers, these pathways ensure that they spend less time grappling with infrastructure complexities and more on actual coding.

An effective IDP in an open-source format would ideally offer these clear, simplified pathways, guiding developers through the intricacies of complex environments.

Identifying bottlenecks

In the case of our platform engineering hero, let’s assume that his journey in building an IDP is guided by two primary challenges:

• The absence of a centralized interface for developers to interact with the infrastructure
• A significant burden in maintaining developer environments

Addressing these challenges will be crucial in the following IDP design development. In the upcoming subsection, we will delve into a specific category of tools designed to address each of these formidable challenges head-on.

Choosing IDP components to address them

To effectively address the distinct challenges identified in our workflow analysis, a strategic approach involves mapping these challenges to specific components of an IDP.

• To address the first challenge—the lack of a centralized interface for infrastructure interaction—we should incorporate components like a developer portal and a software catalog into our IDP. These tools, which are explained below, will serve as a unified platform, offering developers an intuitive and streamlined way to access and manage the diverse array of infrastructure tools.
• To address the second challenge—the cumbersome maintenance of developer environments—we should focus on the environment management component of the IDP, particularly emphasizing ephemeral environments. These temporary, dynamically created environments can significantly reduce the overhead and complexity associated with traditional development environments.

Choosing between open-source and commercial components

As our platform engineer delves deeper into constructing the ideal IDP, he begins to explore various implementations of the required tools, weighing options between open-source and commercial alternatives.

In considering open-source tools, he must carefully evaluate the trade-offs. Open-source options often bring hidden costs, such as the need for ongoing management, regular upgrades, and improvements. Additionally, aspects like user experience (UX) and security might not be as robustly addressed in open-source solutions compared to their commercial counterparts, requiring additional investment in time, resources, and specialized skillsets to bridge these gaps.

‍{{banner-1="/utility-pages/banners"}}

Developer portals and software catalogs

A developer portal serves as a centralized hub where developers can discover, access, and manage resources and tools using templates representing golden paths. A service catalog is a curated catalog of available services and tools that developers can easily request and utilize.

Backstage is one of the leading open-source tools in the industry for effectively implementing both a developer portal and software catalog. Created by Spotify, it stands out as a comprehensive solution for organizations looking to establish a developer portal.

This portal acts as a consolidated access point to the organization’s entire software stack, offering a service catalog for software discovery, documentation access, and infrastructure management. The creation of a unified entry point simplifies collaboration and efficient software management within the organization.

One of the key strengths of Backstage is its native support for Kubernetes integration, an essential feature for organizations utilizing Kubernetes clusters as the primary computing platform. This integration facilitates developers’ access to real-time status information of software deployed on Kubernetes clusters.  

In addition different components of IDPs often support one another - for example Uffizzi provides virtual cluster ephemeral environments in support of Backstage development.  

Through Backstage, developers can effortlessly access cluster data, view details like pod status, and manage deployments without the need for intricate manual processes or complex command-line configurations. The addition of plugins in Backstage further enhances its functionality, allowing for direct cluster creation. Ultimately, Backstage focuses on elevating the developer experience, particularly highlighting the significance of Kubernetes integration in modern software development environments.

Making development environments ephemeral

The transition to ephemeral environments emerged from the necessity for more dynamic and efficient development and testing workflows. This shift was a response to the limitations of traditional, static environments, which often created bottlenecks in software development. Ephemeral environments represent a significant advancement, providing a flexible and resource-efficient approach that aligns perfectly with the needs of continuous integration and delivery (CI/CD) pipelines.

Characterized by their temporary and on-demand nature, ephemeral environments replicate production settings, offering developers and testers a controlled and isolated workspace. Their greatest advantage lies in dramatically reducing the time required for setup and teardown, thus expediting development and testing processes. Additionally, these environments optimize resource use because they exist only as long as they are needed, which helps in minimizing resource waste.

In the context of ephemeral environments, the concept of Kubernetes virtual clusters is particularly relevant. It allows for the creation of isolated, temporary Kubernetes environments within a larger cluster, enhancing resource efficiency and providing a more scalable and flexible approach to environment management.

Integrating a tool like Uffizzi directly into this setup can further streamline the process. Uffizzi offers specialized capabilities for managing these virtual clusters, enabling rapid provisioning and de-provisioning of environments, which aligns perfectly with the dynamic needs of CI/CD workflows in Kubernetes ecosystems.  The lightweight nature of Uffizzi Virtual clusters makes them fast to spin up and down and at a fraction of the cost of a full cluster.

Things you must be aware of

When considering the adoption of open-source tools in building an IDP, it’s important to be aware of the hidden costs that often accompany them.

While open-source solutions may initially seem cost-effective due to their lack of upfront licensing fees, they can incur significant expenses in terms of:

• Customization
• Integration
• Ongoing maintenance

These costs, which are not always apparent at the outset, can accumulate over time, impacting the overall budget for the IDP.

Another critical aspect to consider with open-source tools is their user experience (UX) and security features. Open-source projects may not always match the polished UX of commercial products, potentially leading to a steeper learning curve and reduced productivity for developers.

Similarly, security in open-source tools can require additional attention. They might not include comprehensive security features by default, necessitating extra effort to ensure robust protection against vulnerabilities.

‍{{banner-2="/utility-pages/banners"}}

Conclusion

Creating an IDP requires a custom approach tailored to each organization’s unique needs. The strategy should focus on creating paved roads and golden paths to reduce cognitive load and streamline developer workflows. This approach sets clear, focused goals for the IDP to ensure it effectively supports the team.

For the IDP’s components, it’s crucial to balance open-source and commercial options. Evaluating each component for its integration, cost, user experience, and security is essential. This careful selection of tools and technologies is key to building an IDP that not only boosts developer productivity but also fits well with the organization’s infrastructure and goals.

‍