<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1522071820081-009f0129c71c?w=1600&amp;auto=format&amp;fit=crop&amp;q=80"><h2 id="introduction">Introduction</h2>“Platform Engineering” went from buzzword to established discipline in the span of three years. The 2026 State of DevOps report shows 67% of enterprise engineering orgs now have a dedicated platform team. But having a platform team ≠ having a useful platform.This post is about what separates IDPs (Internal Developer Platforms) that developers love from the ones they route around.<img src="https://images.unsplash.com/photo-1531482615713-2afd69097998?w=1200&amp;auto=format&amp;fit=crop&amp;q=80" alt="Developers collaborating around a shared platform">Photo by <a href="https://unsplash.com/@austindistel">Austin Distel</a> on Unsplash<hr><h2 id="what-is-a-platform-really">What Is a Platform, Really?</h2>The CNCF definition: “A platform for software delivery is a curated distribution of capabilities, tools, and processes that are available as a coherent, reliable service.”Simpler: a platform is the paved road between “I have code” and “code is running in production.” Everything off the paved road (bespoke CI configs, manual infra provisioning, undocumented scripts) is tech debt that platform engineering eliminates.The key insight: a platform is a product. It has customers (developers), a roadmap, SLOs, feedback loops, and a team responsible for its UX. Platform teams that don’t treat it as a product build internal tools nobody uses.<hr><h2 id="the-golden-path-pattern">The Golden Path Pattern</h2>The most impactful concept in modern platform engineering is the golden path: an opinionated, pre-built route that handles 80% of use cases with zero configuration.<div><pre><code>Golden Path: New Service → Production

1. $ platform new service --template node-api
 └── Creates: repo, CI/CD pipeline, staging env, alerts, dashboards

2. Developer writes code

3. $ git push origin main
 └── Runs: lint → test → build → deploy to staging → auto-promote to prod

No Terraform. No Dockerfile. No Kubernetes YAML. No PR to platform team.
</code></pre></div>The golden path abstracts the complexity. Developers who need customization can eject from it, but 80% never need to.<h3 id="anatomy-of-a-golden-path">Anatomy of a Golden Path</h3><div><pre><code># platform.yaml — Golden path service template
kind: ServiceTemplate
metadata:
 name: node-api
spec:
 scaffolding:
 repo:
 source: github.com/platform/templates/node-api
 ci:
 pipeline: standard-node-pipeline
 
 defaults:
 replicas: 2
 resources:
 cpu: "250m"
 memory: "512Mi"
 autoscaling:
 min: 2
 max: 10
 
 observability:
 metrics: true
 tracing: true
 dashboards: auto-provisioned
 
 security:
 imageScan: required
 secretScanning: required
 sast: required
</code></pre></div>When the developer runs <code>platform new service</code>, this template provisions everything. They never see Kubernetes, Terraform, or Prometheus — unless they want to.<hr><h3 id="portal-layer-backstage-still-dominant">Portal Layer: Backstage (Still Dominant)</h3>Backstage remains the default portal choice in 2026, now on v1.30+. The plugin ecosystem has matured significantly.Must-have plugins:<ul><li>Tech Radar — visualize technology choices and migrations</li><li>Cost Insights — per-service cloud cost attribution</li><li>Kubernetes — live pod/deployment status without kubectl</li><li>GitHub Actions — CI status directly in the catalog</li><li>Lighthouse — performance audits for frontend services</li></ul>The honest Backstage critique: initial setup is still painful. Budget 2–3 months for a team to get it production-ready. The long-term payoff is real; the short-term investment is often underestimated.<h3 id="infrastructure-layer-opentofu--terragrunt">Infrastructure Layer: OpenTofu + Terragrunt</h3>Terraform’s 2023 license change accelerated OpenTofu adoption. By 2026, OpenTofu is the default in most new IDP stacks:<div><pre><code># modules/service/main.tf (OpenTofu)
module "service" {
 source = "platform/service/aws"
 version = "~&gt; 3.0"
 
 name = var.service_name
 environment = var.environment
 team = var.team
 
 # All security/compliance defaults built in
 # Developers don't configure these
}
</code></pre></div>Terragrunt manages the DRY layer across environments and accounts.<h3 id="deployment-layer-flux--argocd">Deployment Layer: Flux / ArgoCD</h3>GitOps has won for Kubernetes deployments. The platform controls the GitOps configuration; developers just push code.<div><pre><code>Developer pushes code
 ↓
CI pipeline builds image, pushes to registry
 ↓
CI updates image tag in platform GitOps repo
 ↓
Flux/ArgoCD detects change, reconciles cluster state
 ↓
Rollout with health checks and auto-rollback
</code></pre></div><h3 id="ai-assistance-layer-new-in-2026">AI Assistance Layer (New in 2026)</h3>Platform teams are now embedding AI assistants directly into developer workflows:<ul><li>PR description generation from diff</li><li>Runbook suggestions on alert firing</li><li>Auto-generated dashboards based on service type</li><li>Incident summarization from logs + traces</li></ul>The integration point: platform APIs expose structured data that AI agents consume. Don’t bolt AI on top of undocumented systems.<hr><h2 id="organizational-dynamics">Organizational Dynamics</h2><h3 id="the-team-topology-connection">The Team Topology Connection</h3>Platform teams fit the “platform team” topology in Team Topologies. The relationship with stream-aligned teams should be X-as-a-Service — predictable interfaces, SLOs, and self-service.Common failure mode: platform teams that operate as gatekeepers rather than enablers. Symptoms:<ul><li>PRs to platform team required for common changes</li><li>Platform roadmap driven by platform preferences, not developer needs</li><li>“Just use Kubernetes” as the answer to every request</li></ul><h3 id="measuring-platform-success">Measuring Platform Success</h3>Vanity metrics: number of services onboarded, pipeline count Real metrics:<ul><li>DORA metrics for teams using the platform vs. not</li><li>Time from commit to production (golden path benchmark)</li><li>Developer satisfaction (quarterly NPS specifically about platform)</li><li>Platform adoption rate (% of services on golden path)</li><li>Toil hours saved (estimate from before/after interviews)</li></ul><h3 id="the-paved-road-vs-walled-garden-balance">The “Paved Road” vs. “Walled Garden” Balance</h3>The tension every platform team faces: provide enough opinionation to enforce security/consistency, without so many restrictions that teams build shadow IT to escape.Practical balance:<ul><li>Enforce: Security controls, secret management, observability standards</li><li>Default but escapable: Technology choices, resource sizing, deployment strategy</li><li>Fully optional: Language/framework, database choice, architecture style</li></ul><hr><h2 id="anti-patterns-to-avoid">Anti-Patterns to Avoid</h2>Building for the 20%: Designing the platform around edge cases instead of the common path. The 20% who need custom configs can handle it themselves; optimize for the 80%.Platform as infrastructure team rename: Same gatekeeping behavior, new job title. Real platform engineering is product thinking + engineering.No developer feedback loop: Building in isolation, then wondering why adoption is low. Embed with stream-aligned teams. Watch them use it.Absorbing all complexity: Platform teams that say yes to every request become bottlenecks. The platform should make teams self-sufficient, not dependent.<hr><h2 id="getting-started-the-minimum-viable-platform">Getting Started: The Minimum Viable Platform</h2>If you’re starting from zero, this is the sequence:<ol><li>Month 1–2: Standardize CI/CD. One pipeline template that all new services use.</li><li>Month 3–4: Standardize observability. Auto-provisioned dashboards + alerts for every service.</li><li>Month 5–6: Service scaffolding. <code>platform new service</code> that wires everything together.</li><li>Month 7+: Portal (Backstage), cost visibility, self-service databases.</li></ol>Don’t start with the portal. Start with the thing that saves developers the most time today.<hr><h2 id="conclusion">Conclusion</h2>Platform engineering is fundamentally a UX problem wearing an infrastructure hat. The teams that succeed obsess over developer experience, treat their platform as a product, and measure success by whether developers actually choose to use it.The tooling in 2026 is excellent. The organizational patterns are well-understood. The gap is almost always product thinking — talking to your customers, understanding their actual pain, and building the paved road they’ll genuinely use.<hr>Further reading:<ul><li>CNCF Platform Engineering Maturity Model</li><li>Team Topologies by Skelton &amp; Pais</li><li>Backstage documentation: Getting Started</li></ul> <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

Introduction
“Platform Engineering” went from buzzword to established discipline in the span of three years. The 2026 State of DevOps report shows 67% of enterprise engineering orgs now have a dedicated platform team. But having a platform team ≠ having a useful platform.
This post is about what separates IDPs (Internal Developer Platforms) that developers love from the ones they route around.
Photo by Austin Distel on Unsplash
What Is a Platform, Really?
The CNCF definition: “A platform for software delivery is a curated distribution of capabilities, tools, and processes that are available as a coherent, reliable service.”
Simpler: a platform is the paved road between “I have code” and “code is running in production.” Everything off the paved road (bespoke CI configs, manual infra provisioning, undocumented scripts) is tech debt that platform engineering eliminates.
The key insight: a platform is a product. It has customers (developers), a roadmap, SLOs, feedback loops, and a team responsible for its UX. Platform teams that don’t treat it as a product build internal tools nobody uses.
The Golden Path Pattern
The most impactful concept in modern platform engineering is the golden path: an opinionated, pre-built route that handles 80% of use cases with zero configuration.
Golden Path: New Service → Production
1. $ platform new service --template node-api
   └── Creates: repo, CI/CD pipeline, staging env, alerts, dashboards
2. Developer writes code
3. $ git push origin main
   └── Runs: lint → test → build → deploy to staging → auto-promote to prod
No Terraform. No Dockerfile. No Kubernetes YAML. No PR to platform team.
The golden path abstracts the complexity. Developers who need customization can eject from it, but 80% never need to.
Anatomy of a Golden Path
# platform.yaml — Golden path service template
kind: ServiceTemplate
metadata:
  name: node-api
spec:
  scaffolding:
    repo:
      source: github.com/platform/templates/node-api
    ci:
      pipeline: standard-node-pipeline
    
  defaults:
    replicas: 2
    resources:
      cpu: "250m"
      memory: "512Mi"
    autoscaling:
      min: 2
      max: 10
    
  observability:
    metrics: true
    tracing: true
    dashboards: auto-provisioned
    
  security:
    imageScan: required
    secretScanning: required
    sast: required
When the developer runs platform new service, this template provisions everything. They never see Kubernetes, Terraform, or Prometheus — unless they want to.
Tool Choices in 2026
Portal Layer: Backstage (Still Dominant)
Backstage remains the default portal choice in 2026, now on v1.30+. The plugin ecosystem has matured significantly.
Must-have plugins:
Tech Radar — visualize technology choices and migrations
Cost Insights — per-service cloud cost attribution
Kubernetes — live pod/deployment status without kubectl
GitHub Actions — CI status directly in the catalog
Lighthouse — performance audits for frontend services
The honest Backstage critique: initial setup is still painful. Budget 2–3 months for a team to get it production-ready. The long-term payoff is real; the short-term investment is often underestimated.
Infrastructure Layer: OpenTofu + Terragrunt
Terraform’s 2023 license change accelerated OpenTofu adoption. By 2026, OpenTofu is the default in most new IDP stacks:
# modules/service/main.tf (OpenTofu)
module "service" {
  source  = "platform/service/aws"
  version = "~> 3.0"
  
  name         = var.service_name
  environment  = var.environment
  team         = var.team
  
  # All security/compliance defaults built in
  # Developers don't configure these
}
Terragrunt manages the DRY layer across environments and accounts.
Deployment Layer: Flux / ArgoCD
GitOps has won for Kubernetes deployments. The platform controls the GitOps configuration; developers just push code.
Developer pushes code
        ↓
CI pipeline builds image, pushes to registry
        ↓
CI updates image tag in platform GitOps repo
        ↓
Flux/ArgoCD detects change, reconciles cluster state
        ↓
Rollout with health checks and auto-rollback
AI Assistance Layer (New in 2026)
Platform teams are now embedding AI assistants directly into developer workflows:
PR description generation from diff
Runbook suggestions on alert firing
Auto-generated dashboards based on service type
Incident summarization from logs + traces
The integration point: platform APIs expose structured data that AI agents consume. Don’t bolt AI on top of undocumented systems.
Organizational Dynamics
The Team Topology Connection
Platform teams fit the “platform team” topology in Team Topologies. The relationship with stream-aligned teams should be X-as-a-Service — predictable interfaces, SLOs, and self-service.
Common failure mode: platform teams that operate as gatekeepers rather than enablers. Symptoms:
PRs to platform team required for common changes
Platform roadmap driven by platform preferences, not developer needs
“Just use Kubernetes” as the answer to every request
Measuring Platform Success
Vanity metrics: number of services onboarded, pipeline count
Real metrics:
DORA metrics for teams using the platform vs. not
Time from commit to production (golden path benchmark)
Developer satisfaction (quarterly NPS specifically about platform)
Platform adoption rate (% of services on golden path)
Toil hours saved (estimate from before/after interviews)
The “Paved Road” vs. “Walled Garden” Balance
The tension every platform team faces: provide enough opinionation to enforce security/consistency, without so many restrictions that teams build shadow IT to escape.
Practical balance:
Enforce: Security controls, secret management, observability standards
Default but escapable: Technology choices, resource sizing, deployment strategy
Fully optional: Language/framework, database choice, architecture style
Anti-Patterns to Avoid
Building for the 20%: Designing the platform around edge cases instead of the common path. The 20% who need custom configs can handle it themselves; optimize for the 80%.
Platform as infrastructure team rename: Same gatekeeping behavior, new job title. Real platform engineering is product thinking + engineering.
No developer feedback loop: Building in isolation, then wondering why adoption is low. Embed with stream-aligned teams. Watch them use it.
Absorbing all complexity: Platform teams that say yes to every request become bottlenecks. The platform should make teams self-sufficient, not dependent.
Getting Started: The Minimum Viable Platform
If you’re starting from zero, this is the sequence:
Month 1–2: Standardize CI/CD. One pipeline template that all new services use.
Month 3–4: Standardize observability. Auto-provisioned dashboards + alerts for every service.
Month 5–6: Service scaffolding. platform new service that wires everything together.
Month 7+: Portal (Backstage), cost visibility, self-service databases.
Don’t start with the portal. Start with the thing that saves developers the most time today.
Conclusion
Platform engineering is fundamentally a UX problem wearing an infrastructure hat. The teams that succeed obsess over developer experience, treat their platform as a product, and measure success by whether developers actually choose to use it.
The tooling in 2026 is excellent. The organizational patterns are well-understood. The gap is almost always product thinking — talking to your customers, understanding their actual pain, and building the paved road they’ll genuinely use.
Further reading:
CNCF Platform Engineering Maturity Model
Team Topologies by Skelton & Pais
Backstage documentation: Getting Started

Platform Engineering in 2026: Building Internal Developer Platforms That Teams Actually Use

댓글