<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="introduction">Introduction</h2>“DevOps” promised to tear down the wall between development and operations. In practice, at scale, it created a new problem: every team was now responsible for infrastructure they didn’t fully understand, and platform teams were drowning in one-off requests.Platform Engineering is the answer. Instead of forcing developers to become Kubernetes experts, you build a product — an Internal Developer Platform (IDP) — that abstracts away complexity and gives teams a curated, opinionated set of tools that work. According to Gartner, 80% of large software engineering organizations will have platform engineering teams by 2027.This post breaks down the architecture, toolchain, and organizational patterns that make an IDP succeed.<img src="https://images.unsplash.com/photo-1522071820081-009f0129c71c?w=900&amp;q=80" alt="Developer team working at computers"> Photo by <a href="https://unsplash.com/@anniespratt">Annie Spratt</a> on Unsplash<hr><h2 id="1-the-core-insight-the-idp-is-a-product">1. The Core Insight: The IDP Is a Product</h2>The teams that fail at platform engineering treat it as an infrastructure project. The teams that succeed treat it as a product with:<ul><li>Customers: application development teams</li><li>Product manager: someone who talks to devs, gathers feedback, prioritizes features</li><li>SLA: the platform has uptime, latency, and support commitments</li><li>Changelog: new features are announced; breaking changes have migration guides</li></ul>This mindset shift is more important than any technology choice.<hr><h2 id="2-the-golden-path">2. The Golden Path</h2>A “golden path” is an opinionated, pre-validated route for common tasks. It’s not a mandate — teams can deviate — but the golden path is so low-friction that most won’t bother.<h3 id="example-golden-path-components">Example golden path components</h3><div><pre><code>Developer wants to ship a new microservice
 │
 ▼
1. Scaffolding
 backstage create-app --template golang-microservice
 → Creates: repo, CI pipeline, Dockerfile, Helm chart, Grafana dashboard, PagerDuty integration

2. Local Development
 make dev
 → Spins up: service + dependencies via docker-compose + live reload

3. Preview Environments
 git push origin feature/my-feature
 → Auto-creates: ephemeral namespace in staging cluster
 → URL: https://my-feature.preview.internal.company.com

4. Production Deployment
 git merge main
 → Triggers: CI → image build → Argo CD sync → canary rollout
 → Auto-rollback: if error rate &gt; 1% in first 10 minutes

5. Observability (automatic)
 → Metrics: pre-configured in Grafana
 → Traces: OTEL auto-instrumented
 → Logs: shipped to Loki/Elasticsearch
 → Alerts: baseline alerts pre-configured in Alertmanager
</code></pre></div>A developer can go from idea to production-ready service in under 30 minutes, without filing a ticket or talking to a platform engineer.<hr><h3 id="developer-portal--backstage">Developer Portal — Backstage</h3>Spotify’s Backstage has become the de facto standard for IDP portals. It provides:<ul><li>Software Catalog: every service, its owner, runbook, and SLO in one place</li><li>Tech Docs: docs-as-code, rendered alongside the service</li><li>Templates (Scaffolder): opinionated service creation</li><li>Plugins: 200+ community plugins (AWS, GitHub, PagerDuty, Kubernetes, etc.)</li></ul><div><pre><code># catalog-info.yaml — lives in every repo
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
 name: payment-service
 description: Handles all payment processing
 annotations:
 github.com/project-slug: acme/payment-service
 grafana/dashboard-selector: service=payment-service
 pagerduty.com/service-id: P1234
 backstage.io/techdocs-ref: dir:.
 tags: [payments, critical, go]
spec:
 type: service
 lifecycle: production
 owner: team-payments
 system: checkout-platform
 dependsOn:
 - component:postgres-payments
 - component:stripe-gateway
 providesApis:
 - payment-api
</code></pre></div><h3 id="gitops--argo-cd--argo-rollouts">GitOps — Argo CD + Argo Rollouts</h3><div><pre><code># Canary rollout — Argo Rollouts
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: payment-service
spec:
 replicas: 20
 strategy:
 canary:
 steps:
 - setWeight: 5 # 5% of traffic → canary
 - pause: { duration: 5m }
 - analysis:
 templates:
 - templateName: success-rate
 - setWeight: 25
 - pause: { duration: 10m }
 - setWeight: 50
 - pause: { duration: 10m }
 - setWeight: 100
 canaryService: payment-service-canary
 stableService: payment-service-stable
 trafficRouting:
 istio:
 virtualService: payment-service-vsvc
 selector:
 matchLabels:
 app: payment-service
 template: ...
</code></pre></div><h3 id="infrastructure--crossplane">Infrastructure — Crossplane</h3>Crossplane lets developers provision cloud resources (RDS, S3, Redis) through Kubernetes CRDs, governed by platform-defined policies:<div><pre><code># Developer claims a managed Postgres instance
apiVersion: database.platform.company.com/v1alpha1
kind: PostgreSQLInstance
metadata:
 name: my-service-db
 namespace: team-checkout
spec:
 parameters:
 storageGB: 20
 tier: standard # platform team defines what "standard" means
 region: ap-northeast-2
 writeConnectionSecretToRef:
 name: my-service-db-conn
</code></pre></div>The platform team defines what <code>tier: standard</code> means (instance class, backup policy, maintenance window) — the developer doesn’t need to know.<hr><h2 id="4-self-service-environments">4. Self-Service Environments</h2>On-demand environments are one of the highest-leverage investments a platform team can make. The productivity gains from “I can test this in isolation without touching shared staging” compound across every team.<h3 id="architecture-for-ephemeral-namespaces">Architecture for ephemeral namespaces</h3><div><pre><code>#!/usr/bin/env bash
# create-preview-env.sh — called by CI on PR open

BRANCH=${GITHUB_HEAD_REF}
NAMESPACE="preview-${BRANCH//\//-}"
DOMAIN="${NAMESPACE}.preview.internal.company.com"

# Create namespace with auto-cleanup label
kubectl create namespace "$NAMESPACE" --dry-run=client -o yaml | \
 kubectl annotate --local -f - \
 "preview.platform.company.com/expire-after=72h" \
 "preview.platform.company.com/pr=${PR_NUMBER}" \
 -o yaml | kubectl apply -f -

# Apply namespace-scoped resource quotas
kubectl apply -f - &lt;&lt;EOF
apiVersion: v1
kind: ResourceQuota
metadata:
 name: preview-quota
 namespace: $NAMESPACE
spec:
 hard:
 requests.cpu: "4"
 requests.memory: 8Gi
 limits.cpu: "8"
 limits.memory: 16Gi
 count/pods: "20"
EOF

# Deploy the application via Helm
helm upgrade --install "${NAMESPACE}" ./charts/app \
 --namespace "$NAMESPACE" \
 --set image.tag="${PR_SHA}" \
 --set ingress.host="${DOMAIN}" \
 --set env=preview

echo "Preview environment ready: https://${DOMAIN}"
</code></pre></div>A CronJob cleans up namespaces past their <code>expire-after</code> annotation, so environments don’t accumulate.<hr><h2 id="5-measuring-platform-success">5. Measuring Platform Success</h2>Don’t track tickets closed or deployments per day. Track what developers actually care about:<table><thead><tr><th>Metric</th><th>How to Measure</th><th>Target</th></tr></thead><tbody><tr><td>Time to first deployment</td><td>From repo creation → first prod deploy</td><td>&lt; 1 day</td></tr><tr><td>Deployment frequency</td><td>Deployments/team/week</td><td>&gt; 5×</td></tr><tr><td>Change fail rate</td><td>% of deployments causing incidents</td><td>&lt; 5%</td></tr><tr><td>MTTR</td><td>Mean time to restore after incident</td><td>&lt; 30 min</td></tr><tr><td>Developer satisfaction</td><td>Quarterly NPS / SPACE survey</td><td>&gt; 40</td></tr><tr><td>Platform adoption</td><td>% of teams using golden path</td><td>&gt; 80%</td></tr></tbody></table>The first four are the classic DORA metrics. The fifth is easy to overlook but crucial — an unused platform is a failed platform.<hr><h2 id="6-common-failure-modes">6. Common Failure Modes</h2>Too much abstraction: Developers can’t debug problems because the platform hides everything. Solution: expose escape hatches (raw <code>kubectl</code>, <code>terraform console</code>) and make them easy to use.Not enough abstraction: The platform just wraps Helm/Terraform with a thin UI. Developers still need to understand the underlying tech. Solution: test your golden path with a developer who has never used Kubernetes.No feedback loop: Platform team ships features nobody asked for. Solution: embed a platform engineer in each product team rotation; run a monthly “platform council.”Treating it as an infrastructure project: No product manager, no roadmap, no SLAs. Solution: hire or designate a platform PM; publish a quarterly roadmap.<hr><h2 id="conclusion">Conclusion</h2>Platform Engineering is not about technology — it’s about building systems that give developers back the cognitive space to focus on their actual product. The Backstage portal, the golden paths, the self-service environments — these are means to an end. The end is: a developer joins your team on Monday and ships their first change to production by Friday, with confidence.That’s the bar. Everything else is details.<hr>What does your IDP look like? I’m always curious to hear what patterns work (and don’t) at different scales. <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

Introduction
“DevOps” promised to tear down the wall between development and operations. In practice, at scale, it created a new problem: every team was now responsible for infrastructure they didn’t fully understand, and platform teams were drowning in one-off requests.
Platform Engineering is the answer. Instead of forcing developers to become Kubernetes experts, you build a product — an Internal Developer Platform (IDP) — that abstracts away complexity and gives teams a curated, opinionated set of tools that work. According to Gartner, 80% of large software engineering organizations will have platform engineering teams by 2027.
This post breaks down the architecture, toolchain, and organizational patterns that make an IDP succeed.
Photo by Annie Spratt on Unsplash
1. The Core Insight: The IDP Is a Product
The teams that fail at platform engineering treat it as an infrastructure project. The teams that succeed treat it as a product with:
Customers: application development teams
Product manager: someone who talks to devs, gathers feedback, prioritizes features
SLA: the platform has uptime, latency, and support commitments
Changelog: new features are announced; breaking changes have migration guides
This mindset shift is more important than any technology choice.
2. The Golden Path
A “golden path” is an opinionated, pre-validated route for common tasks. It’s not a mandate — teams can deviate — but the golden path is so low-friction that most won’t bother.
Example golden path components
Developer wants to ship a new microservice
 │
 ▼
1. Scaffolding
 backstage create-app --template golang-microservice
 → Creates: repo, CI pipeline, Dockerfile, Helm chart, Grafana dashboard, PagerDuty integration
2. Local Development
 make dev
 → Spins up: service + dependencies via docker-compose + live reload
3. Preview Environments
 git push origin feature/my-feature
 → Auto-creates: ephemeral namespace in staging cluster
 → URL: https://my-feature.preview.internal.company.com
4. Production Deployment
 git merge main
 → Triggers: CI → image build → Argo CD sync → canary rollout
 → Auto-rollback: if error rate > 1% in first 10 minutes
5. Observability (automatic)
 → Metrics: pre-configured in Grafana
 → Traces: OTEL auto-instrumented
 → Logs: shipped to Loki/Elasticsearch
 → Alerts: baseline alerts pre-configured in Alertmanager
A developer can go from idea to production-ready service in under 30 minutes, without filing a ticket or talking to a platform engineer.
3. The Toolchain Stack (2026 Edition)
Developer Portal — Backstage
Spotify’s Backstage has become the de facto standard for IDP portals. It provides:
Software Catalog: every service, its owner, runbook, and SLO in one place
Tech Docs: docs-as-code, rendered alongside the service
Templates (Scaffolder): opinionated service creation
Plugins: 200+ community plugins (AWS, GitHub, PagerDuty, Kubernetes, etc.)
# catalog-info.yaml — lives in every repo
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
 name: payment-service
 description: Handles all payment processing
 annotations:
 github.com/project-slug: acme/payment-service
 grafana/dashboard-selector: service=payment-service
 pagerduty.com/service-id: P1234
 backstage.io/techdocs-ref: dir:.
 tags: [payments, critical, go]
spec:
 type: service
 lifecycle: production
 owner: team-payments
 system: checkout-platform
 dependsOn:
 - component:postgres-payments
 - component:stripe-gateway
 providesApis:
 - payment-api
GitOps — Argo CD + Argo Rollouts
# Canary rollout — Argo Rollouts
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: payment-service
spec:
 replicas: 20
 strategy:
 canary:
 steps:
 - setWeight: 5 # 5% of traffic → canary
 - pause: { duration: 5m }
 - analysis:
 templates:
 - templateName: success-rate
 - setWeight: 25
 - pause: { duration: 10m }
 - setWeight: 50
 - pause: { duration: 10m }
 - setWeight: 100
 canaryService: payment-service-canary
 stableService: payment-service-stable
 trafficRouting:
 istio:
 virtualService: payment-service-vsvc
 selector:
 matchLabels:
 app: payment-service
 template: ...
Infrastructure — Crossplane
Crossplane lets developers provision cloud resources (RDS, S3, Redis) through Kubernetes CRDs, governed by platform-defined policies:
# Developer claims a managed Postgres instance
apiVersion: database.platform.company.com/v1alpha1
kind: PostgreSQLInstance
metadata:
 name: my-service-db
 namespace: team-checkout
spec:
 parameters:
 storageGB: 20
 tier: standard # platform team defines what "standard" means
 region: ap-northeast-2
 writeConnectionSecretToRef:
 name: my-service-db-conn
The platform team defines what tier: standard means (instance class, backup policy, maintenance window) — the developer doesn’t need to know.
4. Self-Service Environments
On-demand environments are one of the highest-leverage investments a platform team can make. The productivity gains from “I can test this in isolation without touching shared staging” compound across every team.
Architecture for ephemeral namespaces
#!/usr/bin/env bash
# create-preview-env.sh — called by CI on PR open
BRANCH=${GITHUB_HEAD_REF}
NAMESPACE="preview-${BRANCH//\//-}"
DOMAIN="${NAMESPACE}.preview.internal.company.com"
# Create namespace with auto-cleanup label
kubectl create namespace "$NAMESPACE" --dry-run=client -o yaml | \
 kubectl annotate --local -f - \
 "preview.platform.company.com/expire-after=72h" \
 "preview.platform.company.com/pr=${PR_NUMBER}" \
 -o yaml | kubectl apply -f -
# Apply namespace-scoped resource quotas
kubectl apply -f - <<EOF
apiVersion: v1
kind: ResourceQuota
metadata:
 name: preview-quota
 namespace: $NAMESPACE
spec:
 hard:
 requests.cpu: "4"
 requests.memory: 8Gi
 limits.cpu: "8"
 limits.memory: 16Gi
 count/pods: "20"
EOF
# Deploy the application via Helm
helm upgrade --install "${NAMESPACE}" ./charts/app \
 --namespace "$NAMESPACE" \
 --set image.tag="${PR_SHA}" \
 --set ingress.host="${DOMAIN}" \
 --set env=preview
echo "Preview environment ready: https://${DOMAIN}"
A CronJob cleans up namespaces past their expire-after annotation, so environments don’t accumulate.
5. Measuring Platform Success
Don’t track tickets closed or deployments per day. Track what developers actually care about:
Metric
 How to Measure
 Target
 
Time to first deployment
 From repo creation → first prod deploy
 < 1 day
 
Deployment frequency
 Deployments/team/week
 > 5×
 
Change fail rate
 % of deployments causing incidents
 < 5%
 
MTTR
 Mean time to restore after incident
 < 30 min
 
Developer satisfaction
 Quarterly NPS / SPACE survey
 > 40
 
Platform adoption
 % of teams using golden path
 > 80%
 
The first four are the classic DORA metrics. The fifth is easy to overlook but crucial — an unused platform is a failed platform.
6. Common Failure Modes
Too much abstraction: Developers can’t debug problems because the platform hides everything. Solution: expose escape hatches (raw kubectl, terraform console) and make them easy to use.
Not enough abstraction: The platform just wraps Helm/Terraform with a thin UI. Developers still need to understand the underlying tech. Solution: test your golden path with a developer who has never used Kubernetes.
No feedback loop: Platform team ships features nobody asked for. Solution: embed a platform engineer in each product team rotation; run a monthly “platform council.”
Treating it as an infrastructure project: No product manager, no roadmap, no SLAs. Solution: hire or designate a platform PM; publish a quarterly roadmap.
Conclusion
Platform Engineering is not about technology — it’s about building systems that give developers back the cognitive space to focus on their actual product. The Backstage portal, the golden paths, the self-service environments — these are means to an end. The end is: a developer joins your team on Monday and ships their first change to production by Friday, with confidence.
That’s the bar. Everything else is details.
What does your IDP look like? I’m always curious to hear what patterns work (and don’t) at different scales.

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

댓글