The Platform Engineering Hype Cycle Is Over — Now Comes the Work

Gartner predicted platform engineering would be mainstream by 2026. They were right. But “mainstream” doesn’t mean “done right.” Most companies now have a platform team. Far fewer have a platform that developers actually want to use.

The gap between “we have an IDP” and “developers love our IDP” is where platform engineering value is either created or destroyed.

This post is about closing that gap.

Photo by Marvin Meyer on Unsplash

What Is an Internal Developer Platform, Actually?

An IDP is the curated set of tools, services, and workflows that lets product engineers ship software without becoming infrastructure experts.

The operative word: curated. Not every tool. Not self-serve Kubernetes for its own sake. A thoughtfully assembled system that removes accidental complexity while preserving essential complexity.

A mature IDP covers:

Developer → Platform Interface
├── Service Catalog (what exists, who owns it)
├── Self-Service Provisioning (new services, environments, databases)
├── CI/CD (standardized pipelines, no reinventing the wheel)
├── Observability (logs, metrics, traces — out of the box)
├── Security Policies (enforced automatically, not manually)
└── Documentation (auto-generated where possible)

The Three Laws of Platform Engineering

After watching dozens of IDP projects succeed and fail, three laws consistently separate good from bad:

Law 1: The Platform Is a Product

Your customers are internal developers. Treat them like customers.

• Run user research. Talk to the teams using your platform.
• Measure adoption, not just availability.
• Have a product backlog, not just a Jira board of tech debt.
• Define success in terms of developer outcomes: deploy frequency, lead time, failure rate.

A platform nobody uses is just infrastructure theater.

Law 2: Pave the Golden Path, Don’t Mandate It

The golden path is the opinionated, supported, optimized way to do things. It should be:

• The path of least resistance — easier than doing it yourself
• Not mandatory — teams can escape when they have good reason
• Well-documented — the why, not just the how

Force developers onto your platform and they’ll route around it. Make the platform genuinely easier and they’ll choose it.

Law 3: Reduce Cognitive Load, Not Control

The point of a platform isn’t to control what engineers do. It’s to reduce the cognitive load of doing it.

Cognitive load = mental effort required to ship software.

Every decision a developer shouldn’t have to make (what observability stack? which secret manager? how to set up TLS?) is cognitive load you can absorb into the platform.

Backstage in 2026: The Ecosystem Has Won

Backstage is now the undisputed foundation for service catalogs and developer portals. With 1000+ plugins and adoption at Spotify, Netflix, American Airlines, and thousands of others, the ecosystem question is settled.

What’s changed in 2026:

Backstage Plugins Worth Installing

# Catalog essentials
@backstage/plugin-catalog          # Core catalog
@backstage/plugin-catalog-backend  # Backend APIs
@backstage/plugin-techdocs        # Auto-generated docs

# Developer workflow
@backstage/plugin-scaffolder      # Service templates
@backstage/plugin-cicd-statistics # Pipeline insights

# Observability
@backstage/plugin-kubernetes      # K8s cluster view
@roadiehq/backstage-plugin-datadog # Datadog integration

# Security
@roadiehq/backstage-plugin-security-insights # CVE tracking

The catalog-info.yaml Standard

Every service, every repo gets this file:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  title: Payment Service
  description: Handles all payment processing for the platform
  tags:
    - java
    - payments
    - critical
  annotations:
    github.com/project-slug: myorg/payment-service
    backstage.io/techdocs-ref: dir:.
    pagerduty.com/service-id: PXXXXXX
spec:
  type: service
  lifecycle: production
  owner: payments-team
  system: checkout
  dependsOn:
    - component:order-service
    - resource:payments-db
  providesApis:
    - payment-api

This single file becomes the source of truth for ownership, dependencies, runbooks, and on-call routing.

Self-Service Provisioning: The Golden Path in Action

The highest-value thing a platform team can build: one command to get a new service that’s fully configured, observed, and deployed.

With Backstage scaffolding:

# Template definition
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: new-service-template
  title: New Go Microservice
spec:
  parameters:
    - title: Service Details
      properties:
        serviceName:
          type: string
        team:
          type: string
        tier:
          enum: [critical, standard, dev]
  steps:
    - id: create-repo
      action: publish:github
      input:
        repoUrl: github.com?owner=myorg&repo=$
        
    - id: apply-template
      action: fetch:template
      input:
        url: ./skeleton/go-service
        values:
          name: $
          team: $
          
    - id: register-catalog
      action: catalog:register
      input:
        catalogInfoPath: /catalog-info.yaml
        
    - id: setup-monitoring
      action: datadog:create-service
      input:
        name: $
        tier: $

Developer runs this template → gets a repo with CI/CD, observability, service catalog entry, PagerDuty integration, and runbook template. In 5 minutes. Without talking to platform team.

Measuring Platform Success

Stop measuring platform health by uptime. Measure it by DORA metrics across your engineering org:

Instrument this in your platform. Surface it in Backstage. Let teams see how they’re trending.

The Anti-Patterns That Kill Platforms

The “Just Use Kubernetes” Trap: Exposing raw Kubernetes to developers is not a platform. It’s infrastructure with extra steps. Abstract it.

The Feature Factory Trap: Building features nobody asked for. Talk to developers first.

The Top-Down Mandate: “Everyone must use the platform by Q3.” Mandates generate compliance, not adoption. Build something worth choosing.

The Snowflake Exception Death Spiral: Every exception to the golden path becomes a maintenance burden. Either absorb it into the platform or document why it’s truly exceptional.

Conclusion

Platform engineering has matured from buzzword to discipline. The teams doing it well share a mindset: they’re building a product for internal customers, obsessing over developer experience, and measuring outcomes in shipping velocity — not infrastructure complexity.

Build the golden path. Make it genuinely easier. Measure adoption. Iterate.

That’s it. That’s platform engineering.

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)