<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1551434678-e076c223a692?w=1920&amp;q=80">Platform engineering has emerged as the answer to DevOps complexity. Instead of expecting every developer to be a Kubernetes expert, platform teams build internal developer platforms (IDPs) that abstract away infrastructure while maintaining flexibility.<img src="https://images.unsplash.com/photo-1551434678-e076c223a692?w=800&amp;q=80" alt="Team collaboration"> Photo by <a href="https://unsplash.com/@anniespratt">Annie Spratt</a> on Unsplash<h2 id="the-problem-platform-engineering-solves">The Problem Platform Engineering Solves</h2>DevOps promised developer empowerment. Reality delivered:<ul><li>50+ tools to learn</li><li>YAML sprawl across repos</li><li>Weeks to provision infrastructure</li><li>“Works on my machine” extended to “works in my namespace”</li></ul>The cognitive load crushed productivity. Platform engineering flips the script: Build once, serve many.<h2 id="core-components-of-an-idp">Core Components of an IDP</h2><h3 id="1-service-catalog-backstage">1. Service Catalog (Backstage)</h3>Backstage provides a single pane of glass for all services:<div><pre><code># catalog-info.yaml in each repo
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
 name: order-service
 description: Handles order processing and fulfillment
 annotations:
 github.com/project-slug: myorg/order-service
 pagerduty.com/service-id: P123ABC
 datadoghq.com/dashboard: orders-main
spec:
 type: service
 owner: team-commerce
 lifecycle: production
 dependsOn:
 - component:payment-service
 - resource:orders-db
</code></pre></div>Engineers find services, see ownership, and access docs in one place.<h3 id="2-golden-paths-templates">2. Golden Paths (Templates)</h3>Self-service templates encode best practices:<div><pre><code># backstage template for new Python service
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
 name: python-service
 title: Python Microservice
spec:
 owner: platform-team
 type: service
 parameters:
 - title: Service Info
 required: [name, owner]
 properties:
 name:
 title: Service Name
 type: string
 pattern: '^[a-z0-9-]+$'
 owner:
 title: Owner Team
 type: string
 ui:field: OwnerPicker
 database:
 title: Database
 type: string
 enum: [none, postgres, redis]
 default: none
 steps:
 - id: fetch-template
 action: fetch:template
 input:
 url: ./skeleton
 values:
 name: $
 owner: $
 
 - id: create-repo
 action: publish:github
 input:
 repoUrl: github.com?owner=myorg&amp;repo=$
 
 - id: register-catalog
 action: catalog:register
 input:
 repoContentsUrl: $
</code></pre></div>New services get CI/CD, monitoring, and deployment configured automatically.<h3 id="3-infrastructure-abstraction">3. Infrastructure Abstraction</h3>Hide Kubernetes complexity behind simple interfaces:<div><pre><code># What developers write (Platform API)
apiVersion: platform.company.io/v1
kind: Application
metadata:
 name: order-service
spec:
 image: gcr.io/myorg/order-service:v1.2.3
 replicas: 3
 resources:
 cpu: 500m
 memory: 512Mi
 database:
 type: postgres
 size: small
 ingress:
 host: orders.api.company.io
</code></pre></div><div><pre><code># What the platform generates (Kubernetes resources)
# Deployment, Service, Ingress, HPA, PDB, NetworkPolicy,
# ServiceMonitor, ConfigMap, Secret references, etc.
</code></pre></div><img src="https://images.unsplash.com/photo-1519389950473-47ba0277781c?w=800&amp;q=80" alt="Architecture diagram"> Photo by <a href="https://unsplash.com/@marvelous">Marvin Meyer</a> on Unsplash<h2 id="building-with-crossplane">Building with Crossplane</h2>Crossplane extends Kubernetes to manage any infrastructure:<div><pre><code># Define a composite resource for databases
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
 name: databases.platform.company.io
spec:
 group: platform.company.io
 names:
 kind: Database
 plural: databases
 versions:
 - name: v1
 served: true
 referenceable: true
 schema:
 openAPIV3Schema:
 type: object
 properties:
 spec:
 type: object
 properties:
 engine:
 type: string
 enum: [postgres, mysql]
 size:
 type: string
 enum: [small, medium, large]
---
# Composition - what actually gets created
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
 name: database-aws
spec:
 compositeTypeRef:
 apiVersion: platform.company.io/v1
 kind: Database
 resources:
 - name: rds-instance
 base:
 apiVersion: rds.aws.crossplane.io/v1beta1
 kind: Instance
 spec:
 forProvider:
 engine: postgres
 instanceClass: db.t3.medium
 allocatedStorage: 20
 patches:
 - fromFieldPath: spec.size
 toFieldPath: spec.forProvider.instanceClass
 transforms:
 - type: map
 map:
 small: db.t3.small
 medium: db.t3.medium
 large: db.t3.large
</code></pre></div>Developers request a database; Crossplane provisions it in AWS/GCP/Azure.<h2 id="developer-experience-metrics">Developer Experience Metrics</h2>Track these to measure platform success:<div><pre><code># Platform metrics dashboard
panels:
 - title: Time to First Deployment
 description: How long from repo creation to production
 target: &lt; 1 hour
 
 - title: Deployment Frequency
 description: How often teams deploy per week
 target: &gt; 10/week
 
 - title: Lead Time for Changes
 description: Commit to production
 target: &lt; 1 day
 
 - title: Change Failure Rate
 description: % deployments causing incidents
 target: &lt; 5%
 
 - title: MTTR
 description: Mean time to recovery
 target: &lt; 1 hour
 
 - title: Developer Satisfaction (NPS)
 description: Quarterly survey
 target: &gt; 50
</code></pre></div><h2 id="common-anti-patterns">Common Anti-Patterns</h2><h3 id="1-building-everything-custom">1. Building Everything Custom</h3>❌ Don’t build a custom service mesh, CI system, and observability stack.✅ Use open-source foundations (Backstage, Argo, Crossplane) and customize.<h3 id="2-ignoring-developer-feedback">2. Ignoring Developer Feedback</h3><div><pre><code># Bad: Platform team assumes what developers need
# Good: Continuous feedback loop

def platform_development_cycle():
 while True:
 pain_points = survey_developers()
 prioritized = rank_by_impact(pain_points)
 
 for feature in prioritized[:3]:
 prototype = build_mvp(feature)
 feedback = alpha_test(prototype, volunteer_teams)
 
 if feedback.positive:
 ship_to_all()
 else:
 iterate_or_kill(prototype)
 
 measure_metrics()
</code></pre></div><h3 id="3-mandating-without-value">3. Mandating Without Value</h3>Forced adoption breeds resentment. Make the platform so good that teams choose it.<h3 id="4-over-abstraction">4. Over-Abstraction</h3>Some teams need escape hatches. Allow raw Kubernetes when necessary:<div><pre><code>apiVersion: platform.company.io/v1
kind: Application
metadata:
 name: special-case-service
spec:
 # Standard platform config
 image: gcr.io/myorg/service:v1
 replicas: 3
 
 # Escape hatch for edge cases
 rawResources:
 - apiVersion: v1
 kind: ConfigMap
 metadata:
 name: custom-config
 data:
 special: "value"
</code></pre></div><h2 id="team-structure">Team Structure</h2>Platform engineering needs dedicated investment:<div><pre><code>Platform Team (5-8 engineers)
├── Core Platform (2-3)
│ ├── Kubernetes infrastructure
│ ├── Crossplane compositions
│ └── Security policies
├── Developer Experience (2-3)
│ ├── Backstage development
│ ├── Templates and golden paths
│ └── Documentation
└── Reliability (1-2)
 ├── Observability stack
 ├── SLO management
 └── Incident tooling
</code></pre></div><h2 id="getting-started">Getting Started</h2><ol><li>Survey developers: What causes the most friction?</li><li>Pick one pain point: Don’t boil the ocean</li><li>Build an MVP: Solve that one thing well</li><li>Measure impact: Time saved, satisfaction improved</li><li>Iterate: Add capabilities based on demand</li></ol><h2 id="conclusion">Conclusion</h2>Platform engineering is not about building the perfect platform—it’s about continuously reducing developer friction. Start with the biggest pain point, build just enough abstraction, and iterate based on real feedback.The best platforms feel invisible. Developers deploy code, infrastructure appears, and they never think about YAML. That’s the goal.Resources:<ul><li><a href="https://tag-app-delivery.cncf.io/whitepapers/platforms/">CNCF Platforms White Paper</a></li><li><a href="https://backstage.io/">Backstage.io</a></li><li><a href="https://crossplane.io/">Crossplane.io</a></li><li><a href="https://teamtopologies.com/">Team Topologies</a> (book)</li></ul> <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

Platform engineering has emerged as the answer to DevOps complexity. Instead of expecting every developer to be a Kubernetes expert, platform teams build internal developer platforms (IDPs) that abstract away infrastructure while maintaining flexibility.
Photo by Annie Spratt on Unsplash
The Problem Platform Engineering Solves
DevOps promised developer empowerment. Reality delivered:
50+ tools to learn
YAML sprawl across repos
Weeks to provision infrastructure
“Works on my machine” extended to “works in my namespace”
The cognitive load crushed productivity. Platform engineering flips the script: Build once, serve many.
Core Components of an IDP
1. Service Catalog (Backstage)
Backstage provides a single pane of glass for all services:
# catalog-info.yaml in each repo
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
 name: order-service
 description: Handles order processing and fulfillment
 annotations:
 github.com/project-slug: myorg/order-service
 pagerduty.com/service-id: P123ABC
 datadoghq.com/dashboard: orders-main
spec:
 type: service
 owner: team-commerce
 lifecycle: production
 dependsOn:
 - component:payment-service
 - resource:orders-db
Engineers find services, see ownership, and access docs in one place.
2. Golden Paths (Templates)
Self-service templates encode best practices:
# backstage template for new Python service
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
 name: python-service
 title: Python Microservice
spec:
 owner: platform-team
 type: service
 parameters:
 - title: Service Info
 required: [name, owner]
 properties:
 name:
 title: Service Name
 type: string
 pattern: '^[a-z0-9-]+$'
 owner:
 title: Owner Team
 type: string
 ui:field: OwnerPicker
 database:
 title: Database
 type: string
 enum: [none, postgres, redis]
 default: none
 steps:
 - id: fetch-template
 action: fetch:template
 input:
 url: ./skeleton
 values:
 name: $
 owner: $
 
 - id: create-repo
 action: publish:github
 input:
 repoUrl: github.com?owner=myorg&repo=$
 
 - id: register-catalog
 action: catalog:register
 input:
 repoContentsUrl: $
New services get CI/CD, monitoring, and deployment configured automatically.
3. Infrastructure Abstraction
Hide Kubernetes complexity behind simple interfaces:
# What developers write (Platform API)
apiVersion: platform.company.io/v1
kind: Application
metadata:
 name: order-service
spec:
 image: gcr.io/myorg/order-service:v1.2.3
 replicas: 3
 resources:
 cpu: 500m
 memory: 512Mi
 database:
 type: postgres
 size: small
 ingress:
 host: orders.api.company.io
# What the platform generates (Kubernetes resources)
# Deployment, Service, Ingress, HPA, PDB, NetworkPolicy,
# ServiceMonitor, ConfigMap, Secret references, etc.
Photo by Marvin Meyer on Unsplash
Building with Crossplane
Crossplane extends Kubernetes to manage any infrastructure:
# Define a composite resource for databases
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
 name: databases.platform.company.io
spec:
 group: platform.company.io
 names:
 kind: Database
 plural: databases
 versions:
 - name: v1
 served: true
 referenceable: true
 schema:
 openAPIV3Schema:
 type: object
 properties:
 spec:
 type: object
 properties:
 engine:
 type: string
 enum: [postgres, mysql]
 size:
 type: string
 enum: [small, medium, large]
---
# Composition - what actually gets created
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
 name: database-aws
spec:
 compositeTypeRef:
 apiVersion: platform.company.io/v1
 kind: Database
 resources:
 - name: rds-instance
 base:
 apiVersion: rds.aws.crossplane.io/v1beta1
 kind: Instance
 spec:
 forProvider:
 engine: postgres
 instanceClass: db.t3.medium
 allocatedStorage: 20
 patches:
 - fromFieldPath: spec.size
 toFieldPath: spec.forProvider.instanceClass
 transforms:
 - type: map
 map:
 small: db.t3.small
 medium: db.t3.medium
 large: db.t3.large
Developers request a database; Crossplane provisions it in AWS/GCP/Azure.
Developer Experience Metrics
Track these to measure platform success:
# Platform metrics dashboard
panels:
 - title: Time to First Deployment
 description: How long from repo creation to production
 target: < 1 hour
 
 - title: Deployment Frequency
 description: How often teams deploy per week
 target: > 10/week
 
 - title: Lead Time for Changes
 description: Commit to production
 target: < 1 day
 
 - title: Change Failure Rate
 description: % deployments causing incidents
 target: < 5%
 
 - title: MTTR
 description: Mean time to recovery
 target: < 1 hour
 
 - title: Developer Satisfaction (NPS)
 description: Quarterly survey
 target: > 50
Common Anti-Patterns
1. Building Everything Custom
❌ Don’t build a custom service mesh, CI system, and observability stack.
✅ Use open-source foundations (Backstage, Argo, Crossplane) and customize.
2. Ignoring Developer Feedback
# Bad: Platform team assumes what developers need
# Good: Continuous feedback loop
def platform_development_cycle():
 while True:
 pain_points = survey_developers()
 prioritized = rank_by_impact(pain_points)
 
 for feature in prioritized[:3]:
 prototype = build_mvp(feature)
 feedback = alpha_test(prototype, volunteer_teams)
 
 if feedback.positive:
 ship_to_all()
 else:
 iterate_or_kill(prototype)
 
 measure_metrics()
3. Mandating Without Value
Forced adoption breeds resentment. Make the platform so good that teams choose it.
4. Over-Abstraction
Some teams need escape hatches. Allow raw Kubernetes when necessary:
apiVersion: platform.company.io/v1
kind: Application
metadata:
 name: special-case-service
spec:
 # Standard platform config
 image: gcr.io/myorg/service:v1
 replicas: 3
 
 # Escape hatch for edge cases
 rawResources:
 - apiVersion: v1
 kind: ConfigMap
 metadata:
 name: custom-config
 data:
 special: "value"
Team Structure
Platform engineering needs dedicated investment:
Platform Team (5-8 engineers)
├── Core Platform (2-3)
│ ├── Kubernetes infrastructure
│ ├── Crossplane compositions
│ └── Security policies
├── Developer Experience (2-3)
│ ├── Backstage development
│ ├── Templates and golden paths
│ └── Documentation
└── Reliability (1-2)
 ├── Observability stack
 ├── SLO management
 └── Incident tooling
Getting Started
Survey developers: What causes the most friction?
Pick one pain point: Don’t boil the ocean
Build an MVP: Solve that one thing well
Measure impact: Time saved, satisfaction improved
Iterate: Add capabilities based on demand
Conclusion
Platform engineering is not about building the perfect platform—it’s about continuously reducing developer friction. Start with the biggest pain point, build just enough abstraction, and iterate based on real feedback.
The best platforms feel invisible. Developers deploy code, infrastructure appears, and they never think about YAML. That’s the goal.
Resources:
CNCF Platforms White Paper
Backstage.io
Crossplane.io
Team Topologies (book)

Platform Engineering in 2026: Building Internal Developer Platforms That Work

댓글