The End of YAML Hell: How Platform Engineering Is Reinventing Developer Experience

on Platform engineering, Devops, Developer experience, Idp, Backstage, Kubernetes



The Problem With YAML All the Way Down

Imagine you just joined a new engineering team. Before you can deploy your first service, you need to:

  1. Write a Dockerfile
  2. Create a Kubernetes Deployment, Service, and Ingress
  3. Configure a HorizontalPodAutoscaler
  4. Set up a Prometheus ServiceMonitor
  5. Create Grafana dashboard JSON
  6. Configure a CI/CD pipeline YAML (500 lines)
  7. Set up PagerDuty alerts
  8. Register the service in a service catalog
  9. Request a database via a Jira ticket (3-5 business days)

This is the reality at thousands of companies. “We use Kubernetes and Terraform” sounds impressive until your developers spend 40% of their time on infrastructure configuration instead of building product.

Platform engineering is the response.

Developer Experience Photo by Christina @ wocintechchat.com on Unsplash

What Platform Engineering Actually Is

Platform engineering is building products for your internal developers. The platform team is a product team. Their customers are other engineers. Success is measured by developer productivity, not uptime.

The core artifact is the Internal Developer Platform (IDP): a self-service layer that gives developers everything they need to build, deploy, and operate their services without becoming Kubernetes/Terraform experts.

Platform Engineering
├── Internal Developer Platform (IDP)
│   ├── Service catalog (Backstage or equivalent)
│   ├── Self-service provisioning (click to create DB, queue, etc.)
│   ├── Golden path templates (opinionated, pre-configured starting points)
│   ├── Developer portal (docs, APIs, ownership)
│   └── Automated workflows (PR → CI → staging → production)
├── Platform Services
│   ├── Kubernetes clusters (managed, pre-configured)
│   ├── Observability stack (pre-wired metrics, logs, traces)
│   └── Security tooling (pre-integrated, opinionated)
└── Developer Experience
    ├── Local development that matches production
    ├── Fast feedback loops (<5 min from commit to deployment)
    └── Self-service everything (no Jira tickets to infrastructure team)

The Golden Path Pattern

The golden path is the paved road through the jungle. It’s the opinionated, well-maintained, automated path from code to production that works for 80% of services.

Key insight: You’re not removing choice, you’re reducing the cost of the default. Teams can still veer off the path — but they have to own the consequences.

What a Golden Path Looks Like

# Developer creates a new service by running one command:
# platform new service --template=web-api --name=payment-service

# This generates:
# - Repository with standard structure
# - Pre-configured Dockerfile (multi-stage, security-hardened)
# - Kubernetes manifests (with HPA, resource limits, network policies)
# - CI/CD pipeline (build, test, scan, deploy)
# - Monitoring dashboards (pre-built Grafana)
# - Alerts (Prometheus rules based on RED metrics)
# - Service catalog registration (auto-populated Backstage entry)
# - Runbook template

The developer gets a production-ready service skeleton. No infrastructure knowledge required.

Template Example (Backstage Software Template)

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: web-api-template
  title: Web API Service
  description: Node.js API with full observability, CI/CD, and Kubernetes deployment
spec:
  owner: platform-team
  type: service
  parameters:
  - title: Service Configuration
    properties:
      name:
        title: Service Name
        type: string
        pattern: '^[a-z][a-z0-9-]+$'
      team:
        title: Owning Team
        type: string
      database:
        title: Database
        type: string
        enum: [none, postgresql, mongodb]
  steps:
  - id: fetch-template
    name: Fetch Template
    action: fetch:template
    input:
      url: ./skeleton
      values:
        name: $
        team: $
  - id: create-repo
    name: Create Repository
    action: github:repo:create
    input:
      name: $
      owner: my-org
  - id: provision-infra
    name: Provision Infrastructure
    action: terraform:apply
    input:
      workspace: $
      variables:
        service_name: $
        database_type: $

One template. One command. Full production stack.

The Tooling Landscape in 2026

Backstage: The IDP Foundation

Backstage (from Spotify, now CNCF) has won the service catalog war. Nearly every Platform Engineering team either uses Backstage or builds their own thing that looks like Backstage.

What Backstage gives you:

  • Software catalog (services, APIs, teams, ownership)
  • TechDocs (documentation-as-code integrated with your catalog)
  • Software templates (golden path scaffolding)
  • Plugin ecosystem (1000+ community plugins)

What Backstage requires:

  • Significant investment to set up properly
  • A team to own and maintain it
  • Strong opinions about how you want your platform to work

Alternatives gaining ground:

  • Port (commercial, faster time-to-value)
  • Cortex (strong scorecard/ownership features)
  • OpsLevel (enterprise focus)

Crossplane: Infrastructure as Code for Platforms

Crossplane lets you define infrastructure resources as Kubernetes custom resources, enabling self-service provisioning:

# Developer requests a database by applying this YAML
# (Or via a UI form that generates this)
apiVersion: database.platform.company.com/v1alpha1
kind: PostgreSQLInstance
metadata:
  name: payment-service-db
  namespace: payment-service
spec:
  parameters:
    storageGB: 50
    tier: production
  writeConnectionSecretToRef:
    name: payment-db-connection

Platform team defines the composition (what “tier: production” actually means in AWS/GCP terms). Developer gets a database without knowing what RDS is.

ArgoCD + ApplicationSets: GitOps at Scale

# One ApplicationSet manages all team deployments
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: team-applications
spec:
  generators:
  - git:
      repoURL: https://github.com/company/platform-config
      revision: HEAD
      directories:
      - path: "teams/*/apps/*"
  template:
    spec:
      project: ""
      source:
        repoURL: https://github.com/company/platform-config
        targetRevision: HEAD
        path: ""
      destination:
        server: https://kubernetes.default.svc
        namespace: ""
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Teams push to their directories. ArgoCD syncs automatically. Platform team defines the structure.

Measuring Platform Engineering Success

The trap: measuring platform team output (features shipped, tickets resolved) instead of developer outcomes.

The right metrics:

DORA Metrics (for your platform’s customers)

  • Deployment frequency: Are developers deploying more often?
  • Lead time for changes: Code → production time trending down?
  • Change failure rate: Are deployments more reliable?
  • Mean time to recovery: When things break, how fast is recovery?

Developer Experience Metrics

  • Time to first deployment (new engineers): Measure onboarding friction
  • Self-service ratio: What % of infra requests are self-served vs ticketed?
  • Platform NPS: Quarterly survey — do engineers actually like the platform?

Platform Health Metrics

  • Golden path adoption rate (% of services using standard templates)
  • Compliance score (% of services meeting security/observability requirements)
  • Platform availability (the IDP itself is a product — it needs SLAs)

The Anti-Patterns That Kill Platform Teams

1. Build Before You Understand

The most common failure: building an IDP nobody uses because you didn’t understand what developers actually needed.

Fix: User research. Talk to 10 engineers. Map their pain points. Build the smallest thing that removes the biggest pain.

2. Paving Roads Nobody Walks

A golden path only works if it’s genuinely the path of least resistance. If developers can bypass it with less effort, they will.

Fix: Make the golden path easier than the alternative. Provide escape hatches (off-path is allowed) but make them explicitly harder.

3. Infrastructure Team Wearing Platform Hats

Platform engineering is product engineering. If your “platform team” is actually an infrastructure team that’s been renamed, the culture shift hasn’t happened.

Fix: Hire/develop product managers for the platform. Treat developer satisfaction as a product metric.

4. Ignoring the Long Tail

Templates handle 80% of use cases. The 20% of non-standard services become second-class citizens.

Fix: Document the off-ramp clearly. Provide building blocks (not just templates) for custom needs. Don’t make the golden path a golden cage.

Getting Started: The 90-Day Platform Engineering Roadmap

Days 1-30: Discover

  • Survey developers: what’s their biggest time sink?
  • Map the current deployment journey from commit to production
  • Identify the 3 most common service types in your org

Days 31-60: Build the MVP

  • Service catalog (Backstage or Port) with existing services registered
  • One golden path template for your most common service type
  • Self-service for one common request (database provisioning or environment creation)

Days 61-90: Measure and Iterate

  • Deploy and measure adoption
  • Collect feedback (it will be brutal — that’s good)
  • Prioritize the next most-requested capability

The Business Case

Platform engineering often struggles to get funding because the ROI is diffuse. Here’s how to make the case:

Engineering time saved: If 50 developers each save 2 hours/week on infrastructure tasks, that’s 100 engineer-hours/week. At $150/hour fully-loaded cost, that’s $780K/year in recovered productivity.

Reduced incidents: Teams with mature platforms have 3-5x fewer production incidents. One prevented major outage often justifies an entire platform team.

Faster onboarding: New engineers productive in 1 day vs 2 weeks is a significant cost and culture win.

Compliance at scale: Security and compliance policies enforced in the platform means you don’t need to rely on every team doing the right thing.

Conclusion

Platform engineering is the acknowledgment that developer experience is not a nice-to-have — it’s an engineering discipline. The teams winning in 2026 are the ones who treat their internal developers as customers and build products accordingly.

YAML hell isn’t inevitable. It’s a choice. The alternative is building a platform that makes the right thing the easy thing.

Your developers are writing code that generates revenue. Every hour they spend fighting infrastructure is revenue not generated. Platform engineering is how you give that time back.

*Resources: Backstage.ioCNCF Platforms White PaperTeam Topologies*

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