Internal Developer Platforms Series

Welcome to our blog series dedicated to unraveling the complexities and potential of Internal Developer Platforms (IDPs). Whether you’re a seasoned tech professional or just embarking on your journey into the world of software development, this series is crafted to guide you through the fundamental aspects of IDPs, their pivotal role within modern development ecosystems, and how they can transform your team’s efficiency and creativity.

Part 1: Introduction

Part 2: What is an Internal Developer Platform?

Part 3: Components of an Internal Developer Platform

Part 4: Deployment Options

Part 5: Spotify Backstage

Part 6: Spotify Backstage Functionality

Part 7: Spotify Backstage Core Functionality

Internal Developer Platforms – Part 7: Spotify Backstage Core Functionality

As discussed in the last blog post, Backstage already comes with a lot of built-in features. It’s time to discover those functionalities. In detail, we will cover the following:

  • Backstage Search
  • Backstage Catalogue
  • Backstage Tech Docs
  • Backstage Software Templates
  • Backstage Plug-ins

Backstage Search and Backstage Catalogue

For effective management and administration of software applications, the „Software Catalog“ feature of Backstage offers a centralized system for managing internal software within a company. It serves as a comprehensive listing of all developed applications, with each software component represented by its own entry. This allows for a quick overview of the company’s software availability. Each entry can be enriched with metadata to display dependencies between software components or to define the software type. The Software Catalog also facilitates the assignment of software to specific individuals, groups, or organizational units, making it easier to identify ownership and areas of responsibility. Moreover, each software component has various tabs that provide extensive information and management tools. Additionally, Backstage’s integrated „Backstage Search“ function enables searching the Backstage ecosystem for terms, components, people, and more, with the capability to extend search to the StackOverflow platform and integrate other search engines to customize search logic according to needs.

Backstage Search Functions - Screenshot User Interface Search functions
Spotify Backstage Service Catalog Screenshot of User Interface

Backstage Tech Docs

The „TechDocs“ feature is designed to aid in the management and administration of technical documentation, offering users a centralized platform to view and provide technical documentation for software components. Documentation can be accessed either through a tab on the respective software component’s page or via a button on the sidebar. Initially, developers write the documentation in the common Markdown format, which is then rendered for the website display using the „MkDocs“ Python module by Backstage. Users have the ability to structure the documentation with a table of contents, split the documentation across multiple Markdown files, and enhance TechDocs with additional functionalities through „TechDocs Addons“.

Spotify Backstage Tech Docs - Dashboard shows a lot of tutorials and other types of documentation

Backstage Software Templates

„Software Templates“ provide a smart way for creating new software or infrastructure components. Users are guided through the creation process with a pre-made template, where they can configure the component at each step by entering parameters, culminating in its creation with a simple button click. The output generated by the template is determined by its creator and can vary, including loading skeleton code, creating a new Git repository, or writing input parameters to a file. Additionally, there’s an option to register the newly created component in the Software Catalog. The process can be further customized to meet specific requirements by writing custom template actions, allowing organizations to establish standards and best practices for the creation of certain components.

Software Templates in Spotify Backstage - Interface shows Dashboar, function to create a new component, pre-made Template for use, search function etc.

Integrations and Plugins

Backstage facilitates the integration of external platforms and cloud providers onto a unified platform, leveraging various services that use external providers for storing or publishing Backstage-specific content. For example, the Backstage Software Catalog can access external providers like GitHub to extract relevant information from YAML files, necessary for incorporating software components into the Software Catalog. Fundamentally, Backstage operates as a „single-page“ application, providing a technical framework in which various plugins, implementing desired functionalities, operate. These plugins, including „Core-Features“ provided by default installed plugins, can be extended with additional services via 3rd-party plugins available on the Marketplace. This Marketplace, accessible through the Backstage website, features plugins developed by Spotify, other organizations, or individuals, offering over 134 plugins across categories like „CI/CD,“ „Monitoring,“ „Infrastructure,“ or „Deployment.“ Plugins are typically installed using a package manager like npm, and by manually adding code to Backstage’s source code, integrating them into the existing tooling environment. Examples from the Marketplace include „Scaffolder Git Actions“ Hill or „Argo CD“. While plugins available in the Marketplace are generally free, Spotify also offers „Premium-Plugins“ as part of a paid subscription, developed by Spotify developers and supported officially by Spotify, such as the „Role-Based-Access-Control (RBAC)“ or „Soundcheck“ plugins.

Dashboard Screenshot of Integrations and Plug-Ins for Spotify Backstage. API with 3scale, Architecture Decision Records, AI Assistant - RAG AI

Internal Developer Platforms – Part 6: Spotify Backstage Functionality

We already discussed in the earlier parts of this blog post series that in the context of software development, developers face a myriad of tasks that can be overwhelming. An Internal Developer Platform (IDP) or an Internal Developer Portal can aid developers in addressing these tasks more efficiently, thereby reducing their cognitive workload. 

Let’s discuss the challenges developers may encounter during software development and show how a platform like Backstage can support developers in overcoming these challenges in the following. We will discuss problems that can be solved with Backstage out-of-the box.

Management of software applications

New developer during the onboarding process in a company are often lacking an adequate system for managing and accessing existing software applications. This inadequacy makes it difficult for the newcomer to grasp the company’s IT infrastructure, find and understand the software available, and know who is responsible for what within the development process. Such challenges include not knowing who oversees certain software, who contributes to its development, or what framework versions are used. Additionally, new developers might be unaware of dependencies that the company’s applications have on other systems like databases or interfaces, leading to potential complexities due to the lack of documentation. As development progresses, further inquiries may arise, such as the existence of software pipelines for specific applications or the details of the software deployment process. While experienced developers could offer assistance, this would result in productivity losses by diverting valuable resources. In summary, the absence of a dedicated tool can significantly delay a developer’s ability to begin contributing productively to software creation.

Working with documentation

Besides, new developers may face challenges, particularly with software documentation during the onboarding process. Without a dedicated software system, accessing information about existing software becomes difficult. Even if information about what specific software does is available within the company, locating this information is not straightforward for new developers. Documentation may be scattered across various platforms such as Google Docs, Readme files, Confluence, or GitHub Pages. Centralized document management and access might either be non-existent or only possible through cumbersome and inefficient methods, like navigating through disorganized collections of links. Moreover, even if the right documentation is found, there’s no guarantee that the information is up-to-date or accurate. Additionally, details about the document’s author or the software version it pertains to might be missing. If a developer discovers an error in the documentation and wishes to report it, identifying and notifying the author can be challenging. Other developers might not be aware of the potential error or could report it again, leading to a non-transparent and inefficient reporting process that negatively impacts productivity. A centralized repository for documentation could potentially solve these issues.

Create software components in a standardized way

Often, the creation of components is not standardized. When building an application with the Angular framework, for example, a developer must first manually generate skeleton code via the command line, requiring knowledge of Angular’s `ng` tool to establish the app’s basic structure. This step is followed by creating a new GitHub repository, pushing the application to it, and setting up software pipelines, all of which demand additional knowledge and time. The developer must also ensure adherence to predefined schemas, standards, and best practices during application development.

Similarly, creating infrastructure components, possibly through GitOps processes, requires understanding GitOps principles and specific details about the component’s definition, including its structure, required parameters, valid values, target Git repository, and operational infrastructure. Manual attention is needed to comply with predefined standards and rules in this scenario too.

For both scenarios, there’s a possibility that the developer may need to modify or delete components post-creation. A tool that consolidates these tasks, automates them, and standardizes the processes would not only relieve mental burden but also save time and reduce the likelihood of errors, allowing developers to quickly return to productive development work.

Integration of external systems

There is a diversity of services available to developers in software development, covering areas like orchestration, databases, Git, deployment, networks, and analytics. These services are typically accessed via the command line or their respective websites, requiring developers to navigate multiple platforms to perform desired actions. The text suggests a significant improvement in efficiency and usability could be achieved by centralizing access to these services on a single platform, allowing developers to perform all necessary actions in one place. For example, obtaining a quick overview of the status of CI pipelines without having to visit GitHub directly. Such a centralized platform should also be flexible enough to incorporate additional services or custom tools to meet the unique needs encountered in software development. Implementing these optimizations could enhance the overall quality of life for developers by simplifying the operation and management of the software landscape, and by increasing productivity in the software development process.

Summary and Outlook

So, it is easy to see, that there are plenty of scenarios where Backstage can really bring benefits out-of-the-box without needing to apply too much customizations.

In the next blog posts, we will have some deep dive into Backstage. In particular, we will introduce the following Backstage core functionalities:

  • Backstage Search
  • Backstage Catalogue
  • Backstage Tech Docs
  • Backstage Software Templates
  • Backstage Plug-ins

Internal Developer Platform – Part 5: Spotify Backstage

Introduction to Backstage

After having written a lot about IDPs in general, it is now time to shift our focus on Spotify Backstage in the next blog posts. Let’s begin with a general introduction.

The Essence and Adoption of Backstage

Backstage is a comprehensive framework designed to go beyond the traditional scope of Internal Developer Portals by offering an open platform capable of constructing tailored developer portals. Distinct from being a standalone Internal Developer Portal written in the blog post series before, Backstage enables development teams to create a portal that align with their specific requirements. Its ongoing development under Spotify underscore its credibility and the innovative approach towards addressing common developmental and operational challenges.

Due to its effectiveness and versatility, Backstage has seen widespread adoption across the tech industry, with over 1000 organizations and more than a million individual developers leveraging the platform. Among its notable users are big IT enterprises such as Netflix, Zalando, and DAZN, showing the platform’s capacity to serve a diverse range of development environments and organizational sizes. This widespread adoption is further validated by Backstage’s inclusion in the „Incubating Projects“ of the Cloud Native Computing Foundation (CNCF), highlighting its potential for future growth and evolution within the cloud-native ecosystem.

The drive behind Backstage’s development was Spotify’s own experience with rapid growth, which brought about significant infrastructural fragmentation and organizational complexities. These challenges, common in fast-scaling tech environments, led to inefficiencies, including reduced productive time for developers and increased cognitive load due to constant context-switching and the need for navigating disparate tools and systems. Backstage was conceived as a solution to these challenges, aiming to streamline and centralize the development process through a unified platform that abstracts away the complexity of underlying infrastructures and toolsets.

Centralization and Customization Through Backstage

Key to Backstage’s functionality is its ability to serve as a central hub for various development-related activities and resources. It offers platform teams the tools to consolidate engineering and organizational tools, resources, technical documentation, and monitoring capabilities for CI/CD pipelines and Kubernetes, among other features. This centralization is facilitated by a user-friendly visualization layer and a variety of self-servicing capabilities, which are foundational to the philosophy of Internal Developer Portals (IDPs). These features are designed to empower developers by providing them with the means to manage software components, rapidly prototype new software projects, and access comprehensive technical documentation—all within a single, integrated platform.

Furthermore, Backstage’s extensible, plugin-based architecture encourages the integration of additional platforms and services, enabling teams to customize and expand their developer portals according to evolving needs. This architecture supports a vibrant ecosystem of plugins, contributed by both external developers and Spotify’s own engineers, available through the Backstage marketplace. This ecosystem not only enhances the platform’s capabilities but also fosters a community of practice around effective development operations (DevOps) and platform engineering principles.

In summary, Backstage represents a strategic tool for addressing the complexities and inefficiencies associated with modern software development and platform engineering. Its development is a response to real-world challenges faced by one of the most innovative companies in the tech sector, and its adoption by leading tech firms underscores its value and effectiveness. Through its comprehensive suite of features, flexible architecture, and supportive community, Backstage offers a promising pathway for organizations looking to enhance their development practices and infrastructure management.

The following table summarizes these keypoints:

Nature of BackstageAn open framework for creating tailored Internal Developer Portals, not just a portal itself.
Development and AdoptionDeveloped by Spotify, with over 1000 adopters and more than a million developers. Notable users include Netflix, Zalando, and DAZN.
CNCF InclusionIncluded in the „Incubating Projects“ of the Cloud Native Computing Foundation (CNCF), indicating potential for growth.
Purpose and OriginCreated to address Spotify’s challenges with infrastructural fragmentation and organizational complexities during rapid growth.
Core FunctionalityServes as a central hub for development tools, resources, technical documentation, and monitoring of CI/CD pipelines and Kubernetes.
Self-Servicing CapabilitiesEmpowers developers with tools for managing software components, prototyping, and accessing technical documentation.
ArchitecturePlugin-based, allowing for integration of additional services and customization to meet evolving needs.
Community and EcosystemSupported by a vibrant ecosystem of plugins, contributed by both Spotify and external developers, available on the Backstage marketplace.

For integrating Backstage into a productive environment, Spotify recommends delegating the portal’s maintenance and development to a dedicated Platform Team. This team is tasked with ensuring that both internal developers and other infrastructure and platform teams transition to actively using the portal. The goal is to establish Backstage as the central platform for all software development activities within the organization. To facilitate the platform’s adoption, Spotify suggests various tactics and identifies metrics to measure the adoption process. These tactics and metrics, while described in the context of Backstage, could generally apply to the adoption of any Internal Developer Platforms or portals. Additionally, the Platform Team is responsible for implementing best practices in consultation with technical leaders or architects.

Internal Developer Platform – Part 4: Deployment Options

In this blog post, we want to discuss the pros and cons of the different deployment options

Deployment options

When introducing an Internal Developer Platform (IDP), companies have basically two option: building it in-house or acquiring a complete package from an external service provider. For in-house development, the responsibility lies with the operations team or a designated „Platform Team“ within the company. This team’s primary functions include creating, further developing, and maintaining the IDP. They closely interact with other organizational members to identify issues at the team and company levels, set basic configurations for applications, and manage permissions. Additional tasks involve ensuring „Standardization by Design,“ managing infrastructure, Service Level Agreements, optimizing workflows, and configuring the IDP to automate recurring processes.

Contrastingly, the Platform-as-a-Service (PaaS) approach involves an external provider offering the platform, taking on these responsibilities. Companies with specific IDP requirements and an in-house Platform Team generally prefer self-development. Instead of starting from scratch, the team can utilize various tools and services to assemble the platform. These tools and services, categorized into platform orchestrators, portals, service catalogs, Kubernetes Control Planes, and Infrastructure Control Planes like Terraform and GitLab CI, each handle specific functionalities of an IDP. Existing tools and technologies like PostgreSQL, Kubernetes, and GitLab CI can be integrated into the IDP.

Backstage Tech Stack

A potential tech stack for an IDP might include Backstage, serving as an internal developer portal with features like a software catalog and tools for monitoring and technical documentation management. Backstage can be extended through plugins for new functionalities. ArgoCD, a GitOps tool, would handle dynamic application deployment in Kubernetes clusters, while Terraform allows developers to provision the desired infrastructure. In addition, companies like Soeldner Consult offer ready to use GitOps plug-ins for the self-service of infrastructure deployments.

Cost considerations

Tool selection often considers cost structures, with distinctions mainly in usage-based or ongoing expenses. While open-source tools like Backstage, ArgoCD, and PostgreSQL are available for free, commercial tools like the Internal Developer Portals „Roadie“ or „configure8“ have usage fees. Despite being open-source, some tools may incur costs for underlying infrastructure operation or developer effort for setup and maintenance. 

Along with the complex cost structure, differences in integration concepts, scope, and hosting models must be considered when selecting tools. The self-development of IDPs presents challenges like increased effort and a steep learning curve for tool implementation, necessitating a capable platform team with the necessary knowledge and resources. While complex configurations may prolong the IDP’s readiness, self-development offers design freedom, allowing the platform team to tailor the platform to specific requirements.

IdP for Startups

For startups, small companies, or organizations lacking the necessary resources and knowledge to independently develop and operate an Internal Developer Platform (IDP), leveraging pre-built solutions from third-party providers might be a practical choice. This route bypasses the complex tasks of setup, maintenance, and further development, as they are primarily executed by the third-party vendor. Similar to custom development, both open-source and closed-source ready-made solutions are available. Typically, these solutions are offered as „Platform-as-a-Service“ (PaaS) products, encompassing a wide array of toolsets. „Mia-Platform“ and „Coherence“ are examples of such platforms. Many providers also allow for the integration of services from external providers, like GitHub repositories or Kubernetes tools, and often feature their own developed tools designed to be integrated into the IDP.

Most providers offer official support, a benefit not always guaranteed with self-developed IDPs. The focus on the IDP concept varies by provider, with some covering the entire software development process as an „End2End“ development process, while others, particularly open-source solutions, may offer only parts of the IDP’s task spectrum. Currently, a comprehensive IDP that is distributed as open-source but also covers most features of a closed-source software does not seem to exist. Closed-source products are generally offered for a monthly fee, with costs dependent on factors like team size, the number of builds completed per month, or the underlying infrastructure used. Due to the predominantly closed-source approach, there is an expectation of reduced design flexibility in the setup and operation of the platform, as well as an increased dependency on the third-party provider.

Internal Developer Platforms – Part 3: Components of IDP’s

Understanding the Components of Internal Developer Platforms (IDP)

After having motivated the advantages of an IDP, we want to focus on the components of an IDP: Internal Developer Platforms (IDP) are designed to streamline and enhance the efficiency of development tasks through a variety of integrated tools and technologies. These platforms comprise six core components that work together to create a cohesive development environment. 

1. Application Configuration Management (ACM) allows you to centralize the management of application configurations. This makes for more convenient management of configurations and enhances service capabilities for such scenarios as microservices, DevOps, and big data. ACM is essential for managing application configurations in a standardized, scalable, and reliable manner. This includes handling various configurations often stored in YAML files, facilitating easier setup changes, versioning, and maintenance. ACM also relates with a proper GitOps strategy, Infrastructure Orchestration (for example with Terraform or Helm) and Environment Management

2. Infrastructure Orchestration (IO): This component integrates the IDP with existing technology setups, including CI/CD pipelines and hardware infrastructure. It ensures that images created during the CI process are correctly deployed into environments like Kubernetes clusters, potentially managed through service accounts provided by cloud operators. Typically, technologies like Terraform or Ansible are used.

3. Environment Management (EM): EM enables developers to create, update, and delete fully provisioned environments at any time without operations team intervention. This promotes efficiency and cost savings by avoiding unnecessary operational expenses and delays. Once again GitOps and a proper GitOps strategy alongside with Infrastructure Orchestration and Deployment Management is crucial.

4. Deployment Management (DM): Focused on integrating CI/CD pipelines, DM allows developers to concentrate on coding by automating building, testing, and deployment processes. This includes selecting the correct environment for image deployment and keeping a record of all deployments for auditing and debugging purposes. Tools like GitLab CI, Tekton or Argo will be a good choice for the integration into to IDP.

5. Role-Based Access Control (RBAC): RBAC controls who can access what within the IDP. By defining roles like Member, Manager, and Admin, IDPs ensure that access is appropriately managed, minimizing unauthorized access and tailoring permissions to the environment type—production or development.

6. Self-Servicing: This feature enables developers to use IDP services without relying on other teams. Self-servicing can be implemented through no-code solutions like graphical user interfaces or through more open solutions like command-line interfaces (CLIs) and APIs. It encompasses accessing templates, creating microservices, and managing software components, promoting a culture of collaboration and innovation across teams and stakeholders.

By integrating these components, Internal Developer Platforms empower developers to work more autonomously, streamline processes, and enhance collaboration across teams, leading to more efficient and innovative development practices.

Summary of Components

The following table recaps these components:

Application Configuration Management (ACM)Manages app configurations in a scalable way, simplifies setup changes, and maintains version control.
Infrastructure Orchestration (IO)Integrates with existing tech tools like Terraform and Ansible and manages the underlying infrastructure
Environment Management (EM)Allows for the creation and management of applicationenvironments.
Deployment Management (DM)Integrates with CI/CD pipelines, enabling developers to focus more on coding than on deployment logistics.
Role-Based Access Control (RBAC)Manages user permissions within the IDP, ensuring secure and appropriate access.
Self-ServicingProvides developers with tools and services for efficient and autonomous project management.

Introducing an IDP

After having discussed the components of an IDP, let’s now discuss how to introduce an IDP in an enterprise environment.

When introducing an Internal Developer Platform (IDP), there are primarily two approaches: self-development or acquisition from an external provider as a complete package. In the case of self-development, the task usually falls to the Operations Team or a designated „Platform Team“ within the company. This team is primarily responsible for creating, developing, maintaining, and optimizing the IDP while ensuring it meets organizational needs.

The Platform Team maintains close communication with the rest of the organization to identify issues at both the team and corporate levels. Their responsibilities include setting basic configurations for applications, managing permissions, ensuring standardization by design, managing infrastructure, service level agreements, optimizing workflows, and configuring the IDP to automate recurring processes.

Alternatively, the Platform as a Service (PaaS) approach involves using a platform provided by an external provider, who takes over the tasks mentioned above.

Companies with specific IDP needs and a capable Platform Team usually prefer the self-development route. Instead of building from scratch, teams can utilize various tools and services to assemble the platform, such as platform orchestrators, portals, service catalogues, Kubernetes control planes, and infrastructure control planes. They can also integrate common tools and technologies, possibly already in use internally, like PostgreSQL databases, Kubernetes for infrastructure, Harbor for image registries, and GitLab CI for continuous integration.

A typical IDP tech stack might include tools like Backstage for internal developer portals, ArgoCD for GitOps, and Terraform for infrastructure provisioning. While some of these tools, like Backstage and ArgoCD, are open-source and free to use, others may have different cost structures, including usage fees. The selection of tools involves considering cost structures, integration concepts, scale, and hosting models. Self-development offers design freedom but comes with challenges such as the increased effort, steep learning curves, and lack of official support for open-source tools, which may necessitate extensive research for technical problems.

Summary of IDP Implementations

ApproachTeam involvedKey responsibilitesBenefitsChallenges
Self-DevelopmentPlatform TeamBuilding and maintaining IDP Managing permissions Standardization and workflow optimizationCustomizability; Integration with existing toolsHigher effort and learning curve Costs for infrastructure and setup
Lack of official support
PaaS (External)External ProviderProviding and maintaining IDP Managing infrastructure and permissionsReduced internal workload Professional supportLess control and customization Potential ongoing costs

Internal Developer Platforms – Part 2: What is an IPD?

What is an Internal Developer Platform (IDP)?

After having introduced Internal Developer Platform in our first blog post of this series, we want to talk about the features of an IDP in more details and write why IDPs matters for companies within a cloud transformation.

First, the concept of an IDP basically consists of three main components:

Firstly, „Internal“ signifies that the platform is designed for use exclusively within an organization. Unlike public or open-source tools, an IDP is tailored to meet the specific requirements and security standards of the company. This focus ensures that internal workflows, data, and processes remain secure and optimized for the company’s unique ecosystem.

Secondly, the „Developer“ component highlights that the primary users of these platforms are the application developers within the organization. The platform is designed with the needs of developers in mind, aiming to streamline their workflows, improve efficiency, and enhance productivity. By centralizing tools and resources, an IDP reduces the complexity developers face, allowing them to focus more on coding and less on administrative or setup tasks.

Thirdly, „Platform“ denotes that the IDP serves as a foundational framework combining various development, deployment, and operational tools into a cohesive environment. This includes integration with version control systems, continuous integration (CI) tools, GitOps practices, databases, and container technologies. By bringing these elements together, the platform facilitates a more streamlined and coherent development lifecycle.

The main objective of an IDP is to simplify and enhance the developer experience by automating processes, centralizing resources, and eliminating unnecessary manual tasks. This includes enabling developers to request resources, initiate pre-provisioned environments, deploy applications, and manage deployments with greater ease and efficiency. As a result, the deployment process, in addition to development, becomes part of the developer’s realm, increasing control and agility.

An IDP typically requires only a coding environment, the Git tool for version control and merging, and the platform itself. This consolidation reduces the need for external websites or the creation of superfluous scripts to execute certain processes or actions, thereby streamlining the entire application development process.

Internal Developer Platforms are generally developed by a dedicated in-house team, known as the Platform Developer Team, which ensures that the platform is customized to fit the company’s needs and goals. However, for companies lacking the resources or expertise to develop their own IDP, there are Platform-as-a-Service (PaaS) options available, providing a complete, out-of-the-box solution from various vendors.

In contrast to IDPs, the term „Internal Developer Portal“ is occasionally mentioned in literature. While it can be used interchangeably with IDP in some contexts, most sources differentiate between the two. The Internal Developer Portal is typically understood as the graphical user interface (GUI) of the IDP, through which developers and sometimes automated systems interact with the platform’s tools and services. This interface simplifies the user experience, making the platform’s functionality more accessible and intuitive.

The Importance of Self-Service

The concept of self-service is a crucial aspect of Internal Developer Platforms (IDP) and significantly enhances their value and utility for developers. Self-service mechanisms within an IDP empower developers by giving them the autonomy to access resources, tools, and environments directly, without needing to wait for approval or intervention from IT operations or other departments. This approach accelerates workflows, promotes efficiency, and reduces bottlenecks in the development cycle.

In a self-service oriented IDP, developers can perform a variety of actions independently. For example, they can request and allocate computational resources, initiate pre-configured environments, deploy applications, and set up automated deployments. Additionally, they can manage scaling, monitor performance, and if necessary, roll back to previous versions of their applications without external assistance. This autonomy not only speeds up the development process but also encourages experimentation and innovation as developers can try out new ideas and solutions quickly and easily.

The self-service capability is underpinned by a user-friendly interface, typically part of the Internal Developer Portal, which simplifies complex operations and makes them accessible to developers of varying skill levels. By abstracting the underlying complexities and automating repetitive tasks, the IDP allows developers to focus more on their core activities, such as coding and problem-solving, rather than on infrastructure management.

Moreover, self-service in IDPs is often governed by predefined policies and templates to ensure that while developers have the freedom to access and deploy resources, they do so in a manner that is secure, compliant, and aligned with the company’s standards and practices. This balance between autonomy and control helps maintain the organization’s operational integrity while enabling the agility required in modern software development.

In summary, self-service is a key feature of Internal Developer Platforms that transforms the developer experience by providing direct access to tools and resources, thereby streamlining the development process, fostering independence, and enabling a more agile and responsive development cycle.

The following table summarizes these elements

Developer AutonomyDevelopers can independently access resources, tools, and environments, eliminating the need for IT operations or other departments‘ intervention.
Speed and EfficiencySelf-service capabilities accelerate workflows and reduce bottlenecks, enabling faster development cycles and promoting efficiency.  
Innovation and ExperimentationEmpowers developers to quickly try new ideas and solutions without prolonged setups or approvals, fostering a culture of innovation.           
User-Friendly InterfaceTypically part of the Internal Developer Portal, it simplifies complex operations, making them accessible and manageable for developers of all skill levels
GovernanceWhile offering freedom, self-service is governed by predefined policies and templates to ensure security, compliance, and adherence to company standards

That’s for this post. In the next post, we will talk about the internal components of an IDP.

Internal Developer Platforms – Part 1: Introduction

In recent years, the software development landscape has undergone significant changes, with terms like „Containerization,“ „Microservices,“ and „Cloud“ becoming increasingly influential. These technologies represent just the tip of the iceberg in a vast array of tools and practices shaping modern software development. The field is continuously evolving, with Artificial Intelligence tools now becoming part of developers‘ everyday toolkit.

Pain Point: Cognitive Load

As the complexity of IT infrastructure grows, so does the cognitive load on developers. They are expected to navigate an ever-expanding universe of tools and technologies, even for basic tasks such as app deployment. This scenario is challenging because developers‘ primary focus should be on coding and creating software efficiently.

Solution: Internal Developer Platform

To address these challenges, leading tech companies like Spotify, Google, Netflix, and Github have developed Internal Developer Platforms (IDPs). These platforms aim to simplify the development process by integrating existing infrastructures and tools, thereby facilitating information exchange throughout the software development lifecycle. IDPs serve to abstract away the underlying complexity, allowing developers to focus more on their primary tasks and less on the intricate details of the technology stack.

The rising interest in such platforms suggests a shift towards more streamlined, efficient development environments. As this trend continues, delving deeper into the technology and understanding its implications for software development could prove beneficial. The ongoing evolution underscores the importance of adapting to new tools and practices in the ever-changing landscape of software development.

Basic Features

Increasingly, cloud providers are offering tools that extend beyond the standard Integrated Development Environment (IDE) to assist developers with ancillary tasks such as management, deployment, and observability. These tools are part of internal platforms, setting them apart from public services like Github, which focus on code management. Recent examples of Internal Developer Platforms (IDPs) include Atlassian and Gitlab. IDPs serve as central hubs, often featuring a „cockpit“ that provides an overview of resources and statuses. Some now incorporate AI to help with routine tasks. The aim of these platforms is to enhance the Developer Experience and reduce cognitive load.

Solutions on the market

More and more commercial vendors provide an IDP based on Spotify Backstage. 

For example, at RedHat,  the core of the Developer Hub announced in May 2023 a self-service portal based on Backstage, where developers can find all the necessary resources for their work, including a software catalog, documentation, and best practices. The portal also offers standardized software templates and pipelines, aiming to simplify the often cumbersome deployment process. For example, Red Hat aims to reduce the cognitive load on teams and make onboarding easier for new members.

Adopting the plugin concept from the underlying Backstage project, vendors have released its own plugins, which are available to customers and the Backstage community. These plugins enhance the portal with features for Continuous Integration/Continuous Delivery (CI/CD), Observability, or Container Management, and the IDP is capable of running non-Red-Hat plugins as well.