•
Platform Engineering DevOps Strategy

IDP vs. IDP: Platform vs. Portal - Clearing the Confusion

"Internal Developer Platform or Internal Developer Portal? They share an acronym but serve different purposes. A deep dive into the difference between the 'Engine' and the 'Interface', and why functionality beats aesthetics."

IDP vs. IDP: Platform vs. Portal - Clearing the Confusion

In the world of Platform Engineering, the acronym IDP is double-booked. It can stand for Internal Developer Platform or Internal Developer Portal.

While marketing teams often use them interchangeably to sell you tools, they represent two distinct layers of your engineering ecosystem. Confusing them is the quickest way to build a beautiful website that does absolutely nothing, or a powerful engine that no one knows how to drive.

Let’s clear the fog.

1. The Internal Developer Platform (The Engine) Link to heading

The Platform is the sum of all your tech. It is the backend engine that powers your software delivery. It exists whether you have a UI for it or not.

  • What it is: A collection of technologies, tools, and workflows bonded together by “Golden Paths” and automation.
  • Components:
    • Infrastructure Orchestrators: Kubernetes, Terraform, Crossplane.
    • CI/CD Pipelines: GitHub Actions, ArgoCD, Jenkins.
    • Identity & Governance: OPA, IAM, Cloud Policy.
    • Backing Services: Postgres RDS, Redis, S3 buckets.
  • Goal: To standardize and automate the provisioning and management of infrastructure.
  • User Interface: Often a CLI (kubectl, terraform), an API, or YAML files.

The Reality Check: If you have a robust set of Terraform modules, a standardized ArgoCD setup, and a well-defined CI/CD pipeline, you have a Platform. It might be a “scrappy” platform, but it’s a platform. You don’t need a fancy website to do Platform Engineering.

2. The Internal Developer Portal (The Interface) Link to heading

The Portal is the interface through which developers interact with the Platform. It is the “single pane of glass” (a buzzword I loathe, but it fits here).

  • What it is: A unified user interface that sits on top of your Platform. It aggregates information and triggers actions.
  • Components:
    • Service Catalog: A searchable directory of all microservices, libraries, and tools. “Who owns the payments-api? Where is its PagerDuty rotation?”
    • Software Scaffolder: A wizard to create new services. “I want a new Java Spring Boot app with a database and CI pipeline.”
    • Scorecards: Automated checks for production readiness. “Does this service have a README? Is it using the latest Node.js version?”
    • TechDocs: Centralized documentation rendered from Markdown.
  • Examples: Backstage, Port, Cortex.
  • Goal: To reduce cognitive load by making the Platform discoverable and easy to consume.

The Reality Check: A Portal without a Platform is just a static website. If your Backstage “Create Service” button just opens a Jira ticket, congratulations: you’ve built a very expensive form.

This is where 2025 trends are heading. Between the Portal (UI) and the Platform (Infra) sits a new category: the Platform Orchestrator (e.g., Humanitec, Kratix).

The Portal captures the intent (“I need a database”). The Orchestrator translates that intent (“Provision an AWS RDS instance, create a user, inject secrets into the K8s namespace”). The Platform executes the request.

Without an orchestrator (or some serious glue code), your Portal is just a collection of hardcoded scripts that break every time AWS changes an API version.

4. Scorecards: Gamifying Quality Link to heading

One of the most powerful features of a Portal is Scorecards.

Platform Engineering isn’t just about provisioning; it’s about governance. But “governance” sounds like a board meeting. “Scorecards” sound like a game.

You can define rules:

  • Has OWNERS file
  • CI pipeline runs in < 5 mins
  • Vulnerability scan passed
  • On-call rotation defined

The Portal scans every service and assigns a grade (A, B, C). Developers are competitive. If Team A sees Team B has an “A+” rating while they have a “C”, they will fix their services. It drives standards adoption without you having to nag anyone.

5. Build vs. Buy: The Backstage Dilemma Link to heading

Backstage (Spotify’s open-source portal) is the elephant in the room. It’s powerful, extensible, and free.

It is also not a product. It is a framework.

Adopting Backstage is not “installing a tool.” It is “starting a new software project.” You need a team of TypeScript developers to build, maintain, and upgrade it. If you have 500+ engineers, it’s worth it. If you have 50, you are likely better off with a SaaS alternative like Port or Cortex, or even a well-structured Wiki + CLI approach (Thinnest Viable Platform).

Rule of Thumb: Don’t build a Portal to manage your Platform until your Platform is stable enough to be managed.

6. Summary: Which Do You Need? Link to heading

Start with the Platform.

  1. Standardize your infrastructure (Golden Paths).
  2. Automate your deployments (GitOps).
  3. Clean up your documentation.

Only then should layer the Portal on top.

  • Platform = Reliability & Speed.
  • Portal = Discoverability & Experience.

The ultimate goal of Platform Engineering is to build a product that developers want to use. The Platform makes it work; the Portal makes it a delight.

Back to Posts