<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1519389950473-47ba0277781c?w=1200&amp;q=80"><h2 id="the-devops-hangover">The DevOps Hangover</h2>For a decade, the promise of DevOps was “you build it, you run it.” In theory: developers own their services end-to-end, break down silos, ship faster. In practice: developers now spend 30-40% of their time wrestling with infrastructure instead of building products.The cognitive load exploded:<ul><li>Choose between 15 different ways to deploy a service</li><li>Manage Kubernetes manifests that span hundreds of lines</li><li>Figure out which secrets manager the team uses this month</li><li>Debug a broken Helm chart at 11 PM</li></ul>Platform Engineering is the industry’s answer. Not a return to the old ops silo, but a product-minded approach to building Internal Developer Platforms (IDPs) — curated, opinionated infrastructure that gives developers golden paths to follow instead of jungles to navigate.<img src="https://images.unsplash.com/photo-1522071820081-009f0129c71c?w=900&amp;q=75" alt="Team collaborating around a screen"> Photo by <a href="https://unsplash.com/@anniespratt">Annie Spratt</a> on Unsplash<hr><h2 id="what-is-an-internal-developer-platform">What Is an Internal Developer Platform?</h2>An IDP is not a portal or a dashboard. It’s a set of integrated capabilities that abstract infrastructure complexity and provide:<ol><li>Self-service provisioning — developers create environments, databases, and queues without filing tickets</li><li>Golden paths — opinionated but flexible templates for the most common patterns</li><li>Guardrails — security and compliance baked in, not bolted on</li><li>Visibility — unified view of services, deployments, and incidents</li></ol>The best IDPs are invisible — developers just write code and push, and things happen correctly.<hr><h2 id="the-idp-capability-map">The IDP Capability Map</h2><table><thead><tr><th>Layer</th><th>Examples</th><th>What it provides</th></tr></thead><tbody><tr><td>Application</td><td>Backstage, Port, Cortex</td><td>Service catalog, docs, health</td></tr><tr><td>Orchestration</td><td>Kubernetes, Nomad</td><td>Container scheduling</td></tr><tr><td>Infrastructure</td><td>Terraform, Crossplane</td><td>Cloud resource provisioning</td></tr><tr><td>Delivery</td><td>ArgoCD, Flux, Tekton</td><td>GitOps, CI/CD pipelines</td></tr><tr><td>Secrets</td><td>Vault, AWS Secrets Manager</td><td>Credential management</td></tr><tr><td>Observability</td><td>OTel, Grafana LGTM</td><td>Traces, metrics, logs</td></tr><tr><td>Networking</td><td>Istio, Cilium, Linkerd</td><td>Service mesh, policy</td></tr></tbody></table>A mature IDP stitches these together behind simple developer interfaces.<hr><h2 id="backstage-the-idp-hub">Backstage: The IDP Hub</h2>Backstage (open-sourced by Spotify) has become the de facto developer portal for large engineering organizations. In 2026, it powers IDPs at Netflix, Airbnb, American Airlines, and thousands of others.Core concepts:<h3 id="software-catalog">Software Catalog</h3>Every service, library, API, and dataset is registered in a machine-readable catalog:<div><pre><code># catalog-info.yaml (lives in the repo)
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
 name: payment-service
 description: Handles payment processing for checkout
 tags:
 - java
 - payments
 - tier-1
 annotations:
 github.com/project-slug: myorg/payment-service
 pagerduty.com/service-id: P123456
 grafana/dashboard-url: https://grafana.internal/d/payment-service
spec:
 type: service
 lifecycle: production
 owner: group:payments-team
 system: checkout
 dependsOn:
 - component:order-service
 - resource:payments-postgres-db
 providesApis:
 - payment-api
</code></pre></div><h3 id="software-templates-golden-paths">Software Templates (Golden Paths)</h3>When a developer needs a new service, they don’t start from scratch — they use a template:<div><pre><code>apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
 name: typescript-microservice
 title: TypeScript Microservice
 description: Create a production-ready TypeScript service with all the bells and whistles
spec:
 owner: platform-team
 type: service

 parameters:
 - title: Service Details
 properties:
 name:
 title: Service Name
 type: string
 pattern: '^[a-z][a-z0-9-]*$'
 description:
 title: Description
 type: string
 team:
 title: Owning Team
 type: string
 ui:field: OwnerPicker

 steps:
 - id: fetch-template
 name: Fetch Template
 action: fetch:template
 input:
 url: ./skeleton
 values:
 name: $
 team: $

 - id: publish
 name: Publish to GitHub
 action: publish:github
 input:
 repoUrl: github.com?repo=$&amp;owner=myorg
 defaultBranch: main

 - id: register
 name: Register in Catalog
 action: catalog:register
 input:
 repoContentsUrl: $
 catalogInfoPath: /catalog-info.yaml

 - id: create-argocd-app
 name: Create ArgoCD Application
 action: argocd:create-application
 input:
 appName: $
 namespace: production
</code></pre></div>With this template, a developer fills out a form, clicks “Create,” and 2 minutes later has:<ul><li>A GitHub repo with CI/CD pipelines pre-configured</li><li>An ArgoCD application pointing at their repo</li><li>A Grafana dashboard pre-created</li><li>An entry in the service catalog</li><li>A PagerDuty service for on-call routing</li></ul>No tickets, no waiting.<hr><h2 id="crossplane-infrastructure-as-code-done-right">Crossplane: Infrastructure as Code, Done Right</h2>If Terraform is “infra in a pipeline,” Crossplane is “infra in Kubernetes.” It lets developers request cloud resources using familiar Kubernetes YAML:<div><pre><code># Developer requests a Postgres database
apiVersion: database.platform.myorg.io/v1alpha1
kind: PostgresDatabase
metadata:
 name: payment-db
 namespace: payment-service
spec:
 size: medium # Platform team defines what "medium" means
 region: ap-northeast-2
 backups: true
 writeConnectionSecretToRef:
 name: payment-db-connection
</code></pre></div>The platform team defines the Composite Resource (XR) that translates this into:<ul><li>An RDS instance with the right instance class</li><li>Automated backups enabled</li><li>Security group rules scoped to the namespace</li><li>A Kubernetes Secret with connection credentials</li></ul>Developers get a database. They never touch AWS console, IAM, or security groups.<hr><h2 id="the-golden-path-in-practice">The Golden Path in Practice</h2>A mature golden path for a new feature looks like:<div><pre><code>Developer workflow (with golden path)
─────────────────────────────────────
1. git checkout -b feature/new-endpoint
2. Write code
3. git push origin feature/new-endpoint
 → Pre-commit hooks run linting/formatting
 → CI pipeline: test + security scan + SBOM generation
4. Open PR
 → PR size bot: "this is a reasonable PR size ✓"
 → Policy bot: "required tests present ✓"
5. Merge to main
 → ArgoCD deploys to staging automatically
 → Synthetic tests run against staging
6. Click "Promote to Production" in Backstage
 → Canary deployment: 5% → 25% → 100% over 30 minutes
 → Automatic rollback if error rate spikes
7. Done. Coffee time.

Without golden path (same feature):
─────────────────────────────────────────────────────────
1-2. Same.
3. Push. Figure out CI config. Where's the CI template again?
4. PR. Debate whether tests are enough. Check security scan manually.
5. Merge. Figure out which ArgoCD app this belongs to. Update Helm values.
 Debug why the image tag is wrong. Where's the ImagePolicy again?
6. SSH into staging to check. Manually edit traffic weights in Istio.
 Monitor error rates in three different dashboards.
7. Done. It's now 2 AM.
</code></pre></div><hr><h2 id="measuring-idp-success-dora--space">Measuring IDP Success: DORA + SPACE</h2>Platform teams are measured on developer productivity metrics:DORA Metrics:<ul><li>Deployment Frequency — how often you ship (elite: multiple/day)</li><li>Lead Time for Changes — PR merge to production (elite: &lt;1 hour)</li><li>Change Failure Rate — % of deployments causing incidents (elite: &lt;5%)</li><li>MTTR — how fast you recover from incidents (elite: &lt;1 hour)</li></ul>SPACE Framework (developer experience):<ul><li>Satisfaction — are devs happy with their tools?</li><li>Performance — quality of outcomes</li><li>Activity — amount of work done</li><li>Communication — collaboration effectiveness</li><li>Efficiency — flow state, low interruptions</li></ul>Track these quarterly. A good IDP moves all of them in the right direction.<hr><h2 id="building-your-idp-the-pragmatic-roadmap">Building Your IDP: The Pragmatic Roadmap</h2>Don’t boil the ocean. A realistic 12-month roadmap:Months 1-3: Foundation<ul><li>Deploy Backstage with service catalog</li><li>Mandate <code>catalog-info.yaml</code> in all new repos</li><li>Create one golden path template for your most common service type</li></ul>Months 4-6: Self-Service<ul><li>Add Crossplane for database/queue provisioning</li><li>Integrate secrets management (Vault or AWS SM)</li><li>Onboard GitOps with ArgoCD</li></ul>Months 7-9: Developer Experience<ul><li>Add pre-built Grafana dashboards for all catalog entries</li><li>Automate on-call routing (PagerDuty integration)</li><li>Build a cost visibility plugin</li></ul>Months 10-12: Polish<ul><li>Run developer satisfaction surveys</li><li>Fix the top 5 pain points reported</li><li>Document and evangelise the golden paths</li></ul><hr><h2 id="conclusion">Conclusion</h2>Platform Engineering isn’t about taking ownership away from developers — it’s about removing the undifferentiated toil that slows them down. A good IDP is like a great road network: you still drive your own car, choose your own destination, take detours when you want — but you don’t have to build the road yourself.The organizations winning in 2026 aren’t the ones with the smartest individual developers. They’re the ones with the best developer experience. Build the platform. Build the golden paths. Watch your team fly.<hr>References:<ul><li><a href="https://backstage.io/">Backstage.io</a></li><li><a href="https://crossplane.io/">Crossplane</a></li><li><a href="https://dora.dev/">DORA Metrics</a></li><li><a href="https://queue.acm.org/detail.cfm?id=3454124">SPACE Framework</a></li><li><a href="https://platformengineering.org/">Platform Engineering Community</a></li><li><a href="https://teamtopologies.com/">Team Topologies (book)</a></li></ul> <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

The DevOps Hangover
For a decade, the promise of DevOps was “you build it, you run it.” In theory: developers own their services end-to-end, break down silos, ship faster. In practice: developers now spend 30-40% of their time wrestling with infrastructure instead of building products.
The cognitive load exploded:
Choose between 15 different ways to deploy a service
Manage Kubernetes manifests that span hundreds of lines
Figure out which secrets manager the team uses this month
Debug a broken Helm chart at 11 PM
Platform Engineering is the industry’s answer. Not a return to the old ops silo, but a product-minded approach to building Internal Developer Platforms (IDPs) — curated, opinionated infrastructure that gives developers golden paths to follow instead of jungles to navigate.
Photo by Annie Spratt on Unsplash
What Is an Internal Developer Platform?
An IDP is not a portal or a dashboard. It’s a set of integrated capabilities that abstract infrastructure complexity and provide:
Self-service provisioning — developers create environments, databases, and queues without filing tickets
Golden paths — opinionated but flexible templates for the most common patterns
Guardrails — security and compliance baked in, not bolted on
Visibility — unified view of services, deployments, and incidents
The best IDPs are invisible — developers just write code and push, and things happen correctly.
The IDP Capability Map
Layer
 Examples
 What it provides
 
Application
 Backstage, Port, Cortex
 Service catalog, docs, health
 
Orchestration
 Kubernetes, Nomad
 Container scheduling
 
Infrastructure
 Terraform, Crossplane
 Cloud resource provisioning
 
Delivery
 ArgoCD, Flux, Tekton
 GitOps, CI/CD pipelines
 
Secrets
 Vault, AWS Secrets Manager
 Credential management
 
Observability
 OTel, Grafana LGTM
 Traces, metrics, logs
 
Networking
 Istio, Cilium, Linkerd
 Service mesh, policy
 
A mature IDP stitches these together behind simple developer interfaces.
Backstage: The IDP Hub
Backstage (open-sourced by Spotify) has become the de facto developer portal for large engineering organizations. In 2026, it powers IDPs at Netflix, Airbnb, American Airlines, and thousands of others.
Core concepts:
Software Catalog
Every service, library, API, and dataset is registered in a machine-readable catalog:
# catalog-info.yaml (lives in the repo)
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
 name: payment-service
 description: Handles payment processing for checkout
 tags:
 - java
 - payments
 - tier-1
 annotations:
 github.com/project-slug: myorg/payment-service
 pagerduty.com/service-id: P123456
 grafana/dashboard-url: https://grafana.internal/d/payment-service
spec:
 type: service
 lifecycle: production
 owner: group:payments-team
 system: checkout
 dependsOn:
 - component:order-service
 - resource:payments-postgres-db
 providesApis:
 - payment-api
Software Templates (Golden Paths)
When a developer needs a new service, they don’t start from scratch — they use a template:
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
 name: typescript-microservice
 title: TypeScript Microservice
 description: Create a production-ready TypeScript service with all the bells and whistles
spec:
 owner: platform-team
 type: service
 parameters:
 - title: Service Details
 properties:
 name:
 title: Service Name
 type: string
 pattern: '^[a-z][a-z0-9-]*$'
 description:
 title: Description
 type: string
 team:
 title: Owning Team
 type: string
 ui:field: OwnerPicker
 steps:
 - id: fetch-template
 name: Fetch Template
 action: fetch:template
 input:
 url: ./skeleton
 values:
 name: $
 team: $
 - id: publish
 name: Publish to GitHub
 action: publish:github
 input:
 repoUrl: github.com?repo=$&owner=myorg
 defaultBranch: main
 - id: register
 name: Register in Catalog
 action: catalog:register
 input:
 repoContentsUrl: $
 catalogInfoPath: /catalog-info.yaml
 - id: create-argocd-app
 name: Create ArgoCD Application
 action: argocd:create-application
 input:
 appName: $
 namespace: production
With this template, a developer fills out a form, clicks “Create,” and 2 minutes later has:
A GitHub repo with CI/CD pipelines pre-configured
An ArgoCD application pointing at their repo
A Grafana dashboard pre-created
An entry in the service catalog
A PagerDuty service for on-call routing
No tickets, no waiting.
Crossplane: Infrastructure as Code, Done Right
If Terraform is “infra in a pipeline,” Crossplane is “infra in Kubernetes.” It lets developers request cloud resources using familiar Kubernetes YAML:
# Developer requests a Postgres database
apiVersion: database.platform.myorg.io/v1alpha1
kind: PostgresDatabase
metadata:
 name: payment-db
 namespace: payment-service
spec:
 size: medium # Platform team defines what "medium" means
 region: ap-northeast-2
 backups: true
 writeConnectionSecretToRef:
 name: payment-db-connection
The platform team defines the Composite Resource (XR) that translates this into:
An RDS instance with the right instance class
Automated backups enabled
Security group rules scoped to the namespace
A Kubernetes Secret with connection credentials
Developers get a database. They never touch AWS console, IAM, or security groups.
The Golden Path in Practice
A mature golden path for a new feature looks like:
Developer workflow (with golden path)
─────────────────────────────────────
1. git checkout -b feature/new-endpoint
2. Write code
3. git push origin feature/new-endpoint
 → Pre-commit hooks run linting/formatting
 → CI pipeline: test + security scan + SBOM generation
4. Open PR
 → PR size bot: "this is a reasonable PR size ✓"
 → Policy bot: "required tests present ✓"
5. Merge to main
 → ArgoCD deploys to staging automatically
 → Synthetic tests run against staging
6. Click "Promote to Production" in Backstage
 → Canary deployment: 5% → 25% → 100% over 30 minutes
 → Automatic rollback if error rate spikes
7. Done. Coffee time.
Without golden path (same feature):
─────────────────────────────────────────────────────────
1-2. Same.
3. Push. Figure out CI config. Where's the CI template again?
4. PR. Debate whether tests are enough. Check security scan manually.
5. Merge. Figure out which ArgoCD app this belongs to. Update Helm values.
 Debug why the image tag is wrong. Where's the ImagePolicy again?
6. SSH into staging to check. Manually edit traffic weights in Istio.
 Monitor error rates in three different dashboards.
7. Done. It's now 2 AM.
Measuring IDP Success: DORA + SPACE
Platform teams are measured on developer productivity metrics:
DORA Metrics:
Deployment Frequency — how often you ship (elite: multiple/day)
Lead Time for Changes — PR merge to production (elite: <1 hour)
Change Failure Rate — % of deployments causing incidents (elite: <5%)
MTTR — how fast you recover from incidents (elite: <1 hour)
SPACE Framework (developer experience):
Satisfaction — are devs happy with their tools?
Performance — quality of outcomes
Activity — amount of work done
Communication — collaboration effectiveness
Efficiency — flow state, low interruptions
Track these quarterly. A good IDP moves all of them in the right direction.
Building Your IDP: The Pragmatic Roadmap
Don’t boil the ocean. A realistic 12-month roadmap:
Months 1-3: Foundation
Deploy Backstage with service catalog
Mandate catalog-info.yaml in all new repos
Create one golden path template for your most common service type
Months 4-6: Self-Service
Add Crossplane for database/queue provisioning
Integrate secrets management (Vault or AWS SM)
Onboard GitOps with ArgoCD
Months 7-9: Developer Experience
Add pre-built Grafana dashboards for all catalog entries
Automate on-call routing (PagerDuty integration)
Build a cost visibility plugin
Months 10-12: Polish
Run developer satisfaction surveys
Fix the top 5 pain points reported
Document and evangelise the golden paths
Conclusion
Platform Engineering isn’t about taking ownership away from developers — it’s about removing the undifferentiated toil that slows them down. A good IDP is like a great road network: you still drive your own car, choose your own destination, take detours when you want — but you don’t have to build the road yourself.
The organizations winning in 2026 aren’t the ones with the smartest individual developers. They’re the ones with the best developer experience. Build the platform. Build the golden paths. Watch your team fly.
References:
Backstage.io
Crossplane
DORA Metrics
SPACE Framework
Platform Engineering Community
Team Topologies (book)

Platform Engineering in 2026: Building Golden Paths That Developers Actually Love

댓글