Platform Engineering: Internal Developer Platforms

Actualizado: 2026-05-03

Platform engineering has emerged as a discipline distinct from DevOps and SRE. The core idea: instead of every team building and operating its own infrastructure, a dedicated team offers an internal platform (IDP — Internal Developer Platform) as a product. The goal is for product teams to deliver value quickly without becoming experts in Kubernetes, Terraform, or the CI system.

Key takeaways

• The problem IDPs solve is organisational, not technical: duplication, cognitive friction, and operational inconsistency between teams.
• A mature IDP combines a developer portal, service catalogue, golden paths, self-service, and observability by default.
• Spotify’s Backstage is the open-source reference, base for most IDPs at large companies, but requires substantial adaptation investment.
• Golden paths are the core value: the “happy path” so subsidised that most follow it by default, without it being mandatory.
• Before 30-50 developers, IDP investment is usually premature.

The Problem It Solves

Past a certain scale (20+ services, 50+ developers), the “each team manages its own stack” pattern becomes expensive for four reasons:

• Duplication. Each team independently solves deployment, observability, secrets, and auth.
• Cognitive friction. A backend developer spends 30-40% of their time on infrastructure tasks outside their specialty.
• Operational inconsistency. Similar problems solved in different ways complicate incidents and audits.
• Reduced mobility. Moving an engineer between teams requires relearning their entire toolchain.

IDPs address this by consolidating the common behind a unified interface, without limiting flexibility where it matters.

What Composes an IDP

A mature IDP typically includes six components:

• Developer portal: unified UI to view, create, and manage services. Spotify’s Backstage^[1] is the open-source reference.
• Service catalogue: inventory with metadata (responsible team, dependencies, SLOs, docs). The IDP’s “database”.
• Golden paths: pre-built templates for common cases that reduce creating a new service to a single command.
• Self-service: product teams can provision resources without manual tickets to the platform team.
• Observability by default: every new service starts with pre-configured metrics, logs, and traces.
• Guardrails, not gates: policies that allow progress but warn or prevent known mistakes.

Backstage as Reference

Backstage^[1], open-sourced by Spotify in 2020, offers four main functions:

• Software catalog: YAML describes services, ownership, docs, and relations. One entry per entity (service, library, website, infrastructure).
• Plugins: ecosystem of over 100 plugins (CI/CD status, Kubernetes, monitoring, docs) in the same portal.
• TechDocs: documentation-as-code, rendered inside the portal.
• Scaffolder: new-component generator from templates in one click.

In practice, Backstage is the base of dozens of internal IDPs at large companies, though it requires substantial investment to adapt to one’s own context.

Golden Paths: The Core Value

A golden path answers: “I want to create a new microservice — what’s the recommended way here?”. The answer is a template that automatically generates:

• Repository with standard structure.
• Configured Dockerfile and CI.
• Kubernetes manifests with resource limits and health checks.
• Pre-created Grafana dashboard.
• Basic error-rate alert on SLO.
• Integration with the company’s auth system.

The key: the golden path isn’t mandatory. Teams can deviate when they need to. But the “happy path” is so clear and subsidised that most follow it by default.

When to Invest in Platform Engineering

Four signals it’s time to formalise an IDP:

• More than 30-50 developers working on interconnected services.
• Visible duplication between teams in configuration, deployment, and observability.
• Incidents whose root cause is “each team does it differently”.
• Slow onboarding — more than two weeks for a new engineer to deploy something useful.

For smaller teams, investment is usually premature. Better to start with good practices and shared scripts, formalising a platform when scale justifies it.

Antipatterns to Avoid

Three frequent mistakes in implementations that don’t end up working:

• Platform team = “renamed DevOps team”. If you only do infrastructure without treating the developer as customer, it isn’t platform engineering.
• IDP as gate, not path. Forcing the product team through the IDP blocks innovation. Offering it as a clearly better option is different.
• Build everything custom. Backstage + plugins + some integrations is enough for most. Reinventing the wheel rarely justifies the cost.

Platform engineering complements SRE: SRE operates what platform builds. Platform costs are better managed with FinOps practices — the IDP can expose cost per team directly in the portal. Backstage integration with Kubernetes lets teams see their pod status directly in the catalogue.

Conclusion

Platform engineering is a mature discipline for organisations of a certain scale. A well-designed IDP frees product-team time, consolidates practices, and reduces operational incidents. But only if treated as a real product with real users — the internal engineers — not as yet another infrastructure project.

1. Backstage