<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1522071820081-009f0129c71c?w=1200&amp;q=80"><h2 id="the-problem-with-yaml-all-the-way-down">The Problem With YAML All the Way Down</h2>Imagine you just joined a new engineering team. Before you can deploy your first service, you need to:<ol><li>Write a <code>Dockerfile</code></li><li>Create a Kubernetes <code>Deployment</code>, <code>Service</code>, and <code>Ingress</code></li><li>Configure a <code>HorizontalPodAutoscaler</code></li><li>Set up a Prometheus <code>ServiceMonitor</code></li><li>Create Grafana dashboard JSON</li><li>Configure a CI/CD pipeline YAML (500 lines)</li><li>Set up PagerDuty alerts</li><li>Register the service in a service catalog</li><li>Request a database via a Jira ticket (3-5 business days)</li></ol>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.<img src="https://images.unsplash.com/photo-1573496359142-b8d87734a5a2?w=1000&amp;q=80" alt="Developer Experience"> Photo by Christina @ wocintechchat.com on Unsplash<hr><h2 id="what-platform-engineering-actually-is">What Platform Engineering Actually Is</h2>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.<div><pre><code>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 (&lt;5 min from commit to deployment)
 └── Self-service everything (no Jira tickets to infrastructure team)
</code></pre></div><hr><h2 id="the-golden-path-pattern">The Golden Path Pattern</h2>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.<h3 id="what-a-golden-path-looks-like">What a Golden Path Looks Like</h3><div><pre><code># 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
</code></pre></div>The developer gets a production-ready service skeleton. No infrastructure knowledge required.<h3 id="template-example-backstage-software-template">Template Example (Backstage Software Template)</h3><div><pre><code>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: $
</code></pre></div>One template. One command. Full production stack.<hr><h3 id="backstage-the-idp-foundation">Backstage: The IDP Foundation</h3>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:<ul><li>Software catalog (services, APIs, teams, ownership)</li><li>TechDocs (documentation-as-code integrated with your catalog)</li><li>Software templates (golden path scaffolding)</li><li>Plugin ecosystem (1000+ community plugins)</li></ul>What Backstage requires:<ul><li>Significant investment to set up properly</li><li>A team to own and maintain it</li><li>Strong opinions about how you want your platform to work</li></ul>Alternatives gaining ground:<ul><li>Port (commercial, faster time-to-value)</li><li>Cortex (strong scorecard/ownership features)</li><li>OpsLevel (enterprise focus)</li></ul><h3 id="crossplane-infrastructure-as-code-for-platforms">Crossplane: Infrastructure as Code for Platforms</h3>Crossplane lets you define infrastructure resources as Kubernetes custom resources, enabling self-service provisioning:<div><pre><code># 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
</code></pre></div>Platform team defines the composition (what “tier: production” actually means in AWS/GCP terms). Developer gets a database without knowing what RDS is.<h3 id="argocd--applicationsets-gitops-at-scale">ArgoCD + ApplicationSets: GitOps at Scale</h3><div><pre><code># 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
</code></pre></div>Teams push to their directories. ArgoCD syncs automatically. Platform team defines the structure.<hr><h2 id="measuring-platform-engineering-success">Measuring Platform Engineering Success</h2>The trap: measuring platform team output (features shipped, tickets resolved) instead of developer outcomes.The right metrics:<h3 id="dora-metrics-for-your-platforms-customers">DORA Metrics (for your platform’s customers)</h3><ul><li>Deployment frequency: Are developers deploying more often?</li><li>Lead time for changes: Code → production time trending down?</li><li>Change failure rate: Are deployments more reliable?</li><li>Mean time to recovery: When things break, how fast is recovery?</li></ul><h3 id="developer-experience-metrics">Developer Experience Metrics</h3><ul><li>Time to first deployment (new engineers): Measure onboarding friction</li><li>Self-service ratio: What % of infra requests are self-served vs ticketed?</li><li>Platform NPS: Quarterly survey — do engineers actually like the platform?</li></ul><h3 id="platform-health-metrics">Platform Health Metrics</h3><ul><li>Golden path adoption rate (% of services using standard templates)</li><li>Compliance score (% of services meeting security/observability requirements)</li><li>Platform availability (the IDP itself is a product — it needs SLAs)</li></ul><hr><h2 id="the-anti-patterns-that-kill-platform-teams">The Anti-Patterns That Kill Platform Teams</h2><h3 id="1-build-before-you-understand">1. Build Before You Understand</h3>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.<h3 id="2-paving-roads-nobody-walks">2. Paving Roads Nobody Walks</h3>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.<h3 id="3-infrastructure-team-wearing-platform-hats">3. Infrastructure Team Wearing Platform Hats</h3>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.<h3 id="4-ignoring-the-long-tail">4. Ignoring the Long Tail</h3>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.<hr><h2 id="getting-started-the-90-day-platform-engineering-roadmap">Getting Started: The 90-Day Platform Engineering Roadmap</h2>Days 1-30: Discover<ul><li>Survey developers: what’s their biggest time sink?</li><li>Map the current deployment journey from commit to production</li><li>Identify the 3 most common service types in your org</li></ul>Days 31-60: Build the MVP<ul><li>Service catalog (Backstage or Port) with existing services registered</li><li>One golden path template for your most common service type</li><li>Self-service for one common request (database provisioning or environment creation)</li></ul>Days 61-90: Measure and Iterate<ul><li>Deploy and measure adoption</li><li>Collect feedback (it will be brutal — that’s good)</li><li>Prioritize the next most-requested capability</li></ul><hr><h2 id="the-business-case">The Business Case</h2>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.<hr><h2 id="conclusion">Conclusion</h2>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.<hr> <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

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:
Write a Dockerfile
Create a Kubernetes Deployment, Service, and Ingress
Configure a HorizontalPodAutoscaler
Set up a Prometheus ServiceMonitor
Create Grafana dashboard JSON
Configure a CI/CD pipeline YAML (500 lines)
Set up PagerDuty alerts
Register the service in a service catalog
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.
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.io
 CNCF Platforms White Paper
 Team Topologies*

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

댓글