Internal Developer Portal vs. Internal Developer Platform: What’s the Difference, and Why Both Matter

As software development becomes increasingly complex and distributed, companies are recognizing the need to provide their developers with tools and resources to help them work more efficiently and effectively. Two common solutions for this are internal developer portals and internal developer platforms. While both serve similar purposes, there are important differences between them. In this post, we’ll explore those differences and why you ultimately need both.

What Is An Internal Developer Platform

An internal developer platform refers to the collection of tooling built by platform engineers and used by developers. It is often a heterogeneous tool chain stitched together in a way to minimize cognitive load for developers without abstracting away important meaning. 

The categories of tooling that compose an internal developer platform include:

• Integrated Development Environments (IDE) like VSCode, JetBrains, etc.
• Version Control Systems (VCS) like GitHub, GitLab, etc.
• Resources like containers, databases, storage, compute, transit, etc.
• Container registries like Docker
• Kubernetes control planes
• Observability
• Vulnerability scanners
• CI tools like CircleCI, GitHub Actions, and Bitbucket
• GitOps tools / CD controllers (Argo CD)
• Infrastructure as Code tools like Terraform, Ansible, and Pulumi
• Standalone platform orchestrators like Humanitec or Shipa
• Internal Developer Portals like configure8 or Backstage

Chances are your organization has a version of this already, though “platform” might be a generous descriptor. For example, it might have limitations around usability, scalability and guardrails.

What Is An Internal Developer Portal

An internal developer portal (“IDP”) is the singular interface to your developer platform. It discovers every aspect of your architecture, organizes it into a knowledge graph, and exposes information as well as actions developers can take in a unified user experience and API. An IDP also leverages its knowledge graph in order to support scenarios that are critically important to other enterprise stakeholders, including in architecture, ops, security, platform and reliability engineering, and FinOps. It is a powerful workflow and analytics tool that enables organizations to build more reliable, secure, cost-efficient software faster.

It Starts With A Universal Catalog

The core of an IDP is its knowledge graph and discovery engine. This is where everything about your architecture and development teams lives - all your applications, services, data pipelines, environments, and resources, as well as key context about each (like owner, documentation, relevant KPIs, tickets, etc.). The discovery engine is what populates this and minimizes drift. The scenarios this metadata supports are where IDPs get interesting.

A standalone catalog supports a number of scenarios on its own. By organizing everything in one place, an IDP alleviates developers’ on-call stress and enables new developers to ramp-up faster, for instance. It also enables transparency for ops so they can easily locate resources and key details from across various clouds, cloud accounts, and on-prem resources.

The key elements of a catalog are its comprehensiveness (i.e., services only? services + K8s? Everything from applications to resources and key context about each, which supports vastly more scenarios for key stakeholders), the flexibility of its data model, and its ease of configuration and maintenance (i.e., single-click and drift-free, or need a team of 5+ dedicated engineers to configure let alone maintain the software and data accuracy). 

IDPs go from nice-to-have to must-buy when you combine the context they enable for users and the knowledge represented in metadata with actions and analytics.

Self-Serve Actions

An IDP isn’t just a living knowledge graph, it’s also a destination where developers can discover and execute self-serve actions. The primary benefit of self-serve actions is freeing developers from repetitive, time-consuming work wiring components together in code while increasing consistency and reliability.

Self-serve actions can refer to a variety of activities, such as those related to:

• Microservice software development lifecycle, such as scaffolding a new service, deploying, reverting, upgrading a package version, etc.;
• Developer Environments, such as extending TTLs, requesting a temporary new environment, etc.;
• Cloud Resources, such as provisioning, modifying, and access requests;
• Data Engineering, such as running an Airflow DAG, spinning up a remote Jupyter notebook, pre-processing data, etc.; and,
• Site Reliability Engineering, such as updating auto-scaling groups, pod counts, etc.

Platform engineers create the actions exposed in the IDP, and employ flexible guardrails around these actions. These are called blueprints or ‘golden paths.’ Once an action is triggered, it orchestrates your existing ‘internal developer platform’ using the developer’s inputs and the platform engineering team’s blueprint. Don’t think your organization has an ‘internal developer platform’ ready to support this? You might be surprised. Golden paths can be built directly in your existing CI tool, for example.

There are numerous benefits to artfully weaving self-serve actions into an IDP built around a universal catalog. For instance, a universal catalog enables a developer to easily discover the specific resource they are looking for, and then click a few buttons to take an approved action (as opposed to hunting across tools and teams to find a resource, gain context about it, and then copying and pasting a variety of values into a separate UI, only to then have to manually update a spreadsheet or similar ‘source of truth’ after the action has been run). 

When you combine a universal catalog and self-serve actions with analytics, an IDP becomes even more indispensable.

Analytics That Improve Your Organization

A comprehensively populated catalog (ahem, more than just services and k8s!) can be used to define and enforce standards as well as query previously disparate data sets to answer powerful questions. After all, it’s only what gets measured that gets managed.

IDPs offer a feature called scorecards, which enables an organization to define standards for architecture migrations, DORA, readiness, maturity, and more. configure8 offers over 40 metrics you can use to define a scorecard and its standards, and tooling that keeps everyone in the loop and making progress toward goals. When you weave self-serve actions into scorecards, you significantly reduce the burden on developers to improve. An IDP enables this, all without context switching.

The IDP’s API can also help organizations achieve high standards. Consider the context regarding the state of the platform contained in the IDP’s metadata. Developers and platform engineers can request this knowledge programmatically to make automated decisions. Imagine prohibiting a deployment because a service isn’t properly configured to meet a reliability standard?

Additionally, leading IDPs offer the ability to query your metadata so you can get answers without wasting time writing scripts and manually analyzing data to comply with security audits, migrations, and compliance initiatives. You can also use this to unlock hidden insights when unifying this previously disparate data (i.e., which resources are orphaned, what services are deployed on the staging cluster, etc.).

Over time, you’ll see more and more use cases emerge for different enterprise stakeholders that leverage a comprehensively populated knowledge graph paired with self-serve actions.

Why Internal Developer Portals and Internal Developer Platforms Matter

You need both to tame sprawl. It’s never been a better time to be a developer. There’s been an explosion in third-party tools and libraries, which enable developers to be more nimble than ever. However, all of this ‘more’ creates a hidden cost … sprawl. Internal developer platform tools have evolved to alleviate the burden of operating increasingly distributed systems; however, this has fragmented essential knowledge across disparate teams and tools. An IDP unifies all of this essential knowledge in one place and enables stakeholders to analyze and take actions via a singular platform experience. You really can’t have one without the other and build reliable modern software with velocity.