DevOps promised developers would be autonomous. Reality? Developers write Terraform, debug Helm charts, and wait for Jira tickets for infrastructure. Platform engineering refocuses where it belongs — on the product. The developer orders an environment, the platform delivers it. Self-service instead of tickets.

What Is Platform Engineering¶

Platform engineering is a discipline that builds and operates an Internal Developer Platform (IDP) — an abstraction layer between developers and infrastructure. Developers don’t write YAML for Kubernetes. Instead, they choose from templates, click “Deploy,” and the platform takes care of the rest.

Gartner predicts that by 2026, 80% of large software organizations will have a platform engineering team. In 2025, this is one of the fastest-growing disciplines in IT — and for good reason: developer cognitive load has reached its limit.

The average developer in an enterprise environment needs to know Git, CI/CD, containerization, Kubernetes, networking, monitoring, secrets management, IAM, compliance rules… That’s not sustainable. The platform hides this complexity behind sensible abstractions.

Five Pillars of a Successful IDP¶

1. Developer Portal (Backstage)¶

Spotify Backstage has become the de facto standard for developer portals. One website where a developer sees:

• Catalog of all services, libraries, and infrastructure
• Documentation (TechDocs — docs-as-code)
• API specifications (OpenAPI, gRPC, AsyncAPI)
• CI/CD pipeline status, deployment, health checks
• Ownership — who owns which service
• Software templates — scaffolding new projects

Backstage in 2025 has over 200 plugins — from Kubernetes to PagerDuty, from SonarQube to cost management. Deployment takes days, not months.

2. Golden Paths¶

A Golden Path is a recommended way to do things right. Not a mandate — a recommendation backed by automation. Want to deploy a new microservice? The Golden Path gives you:

• Project with the right structure, linting rules, Dockerfile
• CI/CD pipeline (pre-configured, tested)
• Monitoring dashboard (Grafana, pre-set alerts)
• Security scanning (SAST, DAST, dependency check)
• Documentation template

Key: the Golden Path must be the easiest path, not the most complex one. If it’s simpler to bypass the platform, developers will do it.

3. Infrastructure as Code Abstraction¶

Developers shouldn’t write Terraform. They should declare what they need — a database, cache, message queue — and the platform ensures delivery. Tools:

• Crossplane: Kubernetes-native infrastructure provisioning — you declare “I want PostgreSQL” and Crossplane creates it in AWS/Azure/GCP
• Kratix: Framework for “platform as a product” — composable promises for infrastructure
• Humanitec Score: Workload specification independent of the platform

Developer declares the need — not the implementation¶

apiVersion: database.platform.core.cz/v1

kind: PostgreSQL

metadata:

name: orders-db

spec:

version: “16”

size: medium # the platform knows what “medium” means

backup: daily

environment: production

4. Self-Service Environments¶

A developer needs a test environment. In the traditional model: Jira ticket → approval → ops team → 3 days. In the IDP model: click in the portal → 5 minutes. Ephemeral environments (Namespace-as-a-Service) are a killer feature of every IDP:

• Preview environments for every pull request
• Automatic cleanup after merge/close
• Pre-seeded test data
• Isolation at namespace or virtual cluster level (vCluster)

5. Observability & Feedback Loop¶

The platform must measure itself. DORA metrics (Deployment Frequency, Lead Time, Change Failure Rate, MTTR) are the foundation, but add:

• Developer Satisfaction (DevEx): Quarterly survey — how satisfied are developers with the platform?
• Time to First Deploy: How quickly can a new developer deploy their first change?
• Platform Adoption: How many teams actively use Golden Paths?
• Ticket Volume: How many manual infrastructure requests remain?

How to Start — A Pragmatic Plan¶

Don’t build the platform from the bottom up. Start from the biggest pain point:

1. Month 1–2: Deploy Backstage as a service catalog. Let teams register their services. Visibility is the first win.
2. Month 3–4: Add software templates — scaffolding new projects through Backstage. Golden Path for the most common use case (e.g., “new Java microservice”).
3. Month 5–6: Self-service environments. Ephemeral namespaces for PR previews. Crossplane for databases.
4. Month 7–12: Expand based on feedback. Add security scanning, cost dashboards, compliance gates.

Organizational Model — Platform Team¶

A platform team is not a rebranding of the ops team. It’s a product team. It has a product owner, user research (developers are customers), a backlog, and a roadmap. Typical size: 3–7 people to start, scaling with the organization.

Critical principle: the platform is opt-in, not a mandate. If you have to force people to use the platform, it’s poorly designed. The best platforms “win” by being simpler than the alternative.

Antipatterns — What to Avoid¶

• “Platform for the platform’s sake”: Building infrastructure without developer validation. Always start from the problem, not the technology.
• Too much abstraction: Hiding Kubernetes completely? Developers won’t be able to debug. The right abstraction is “good defaults, escape hatch available.”
• Big bang release: The platform is built iteratively. MVP in 2 months, not a “perfect platform” in 18 months.
• Ignoring existing tools: Developers are already using some CI/CD, monitoring, IaC. Integrate, don’t replace.
• Zero metrics: Without DORA metrics and developer satisfaction, you don’t know if the platform is helping or hurting.

Summary¶

Platform engineering is not a trend — it’s an answer to the real problem of developer cognitive overload. An Internal Developer Platform with Backstage, Golden Paths, and self-service infrastructure gives developers back the time to do what they do best: write code that solves business problems.

CORE SYSTEMS designs and implements custom Internal Developer Platforms — from Backstage portals to Crossplane infrastructure.