<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1667372393119-3d4c48d07fc9?w=1200"><h2 id="platform-engineering-the-evolution-beyond-devops">Platform Engineering: The Evolution Beyond DevOps</h2>DevOps promised developer empowerment. But somewhere along the way, “you build it, you run it” became “you build it, you configure the CI pipeline, manage the Kubernetes manifests, handle the monitoring, deal with the incidents, and also run it.”Platform Engineering is the course correction.<img src="https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=800" alt="Server Room"> Photo by <a href="https://unsplash.com/@tvick">Taylor Vick</a> on Unsplash<h2 id="the-problem-with-full-stack-devops">The Problem with “Full Stack DevOps”</h2>A typical modern application requires developers to understand:<ul><li>Container orchestration (Kubernetes, ECS)</li><li>Infrastructure as Code (Terraform, Pulumi)</li><li>CI/CD pipelines (GitHub Actions, GitLab CI)</li><li>Observability (Prometheus, Grafana, OpenTelemetry)</li><li>Service mesh (Istio, Linkerd)</li><li>Secrets management (Vault, AWS Secrets Manager)</li><li>Database operations</li><li>Security compliance</li></ul>That’s not empowerment—it’s cognitive overload.<h2 id="what-is-platform-engineering">What is Platform Engineering?</h2>Platform Engineering treats the platform as a product, with developers as customers. The goal: golden paths that make the right thing the easy thing.<div><pre><code>Traditional DevOps:
Developer → Learn Kubernetes → Configure Helm → Set up monitoring → Deploy

Platform Engineering:
Developer → Create service in portal → Deploy
(Platform team handles the complexity underneath)
</code></pre></div><h2 id="building-your-internal-developer-platform-idp">Building Your Internal Developer Platform (IDP)</h2><h3 id="the-five-planes-model">The Five Planes Model</h3><div><pre><code>┌─────────────────────────────────────────────┐
│ Developer Portal (UI) │
├─────────────────────────────────────────────┤
│ Service Catalog &amp; Templates │
├─────────────────────────────────────────────┤
│ Automation &amp; Orchestration Layer │
├─────────────────────────────────────────────┤
│ Infrastructure Abstraction │
├─────────────────────────────────────────────┤
│ Cloud Resources Layer │
└─────────────────────────────────────────────┘
</code></pre></div><h3 id="1-developer-portal-with-backstage">1. Developer Portal with Backstage</h3><div><pre><code>// catalog-info.yaml - Service Definition
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
 name: payment-service
 description: Handles payment processing
 annotations:
 github.com/project-slug: myorg/payment-service
 backstage.io/kubernetes-id: payment-service
 pagerduty.com/service-id: PXXXXXX
spec:
 type: service
 lifecycle: production
 owner: team-payments
 system: checkout-system
 providesApis:
 - payment-api
 dependsOn:
 - component:user-service
 - resource:payments-db
</code></pre></div><h3 id="2-self-service-templates">2. Self-Service Templates</h3><div><pre><code># scaffolder-template.yaml
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
 name: microservice-template
 title: Create New Microservice
 description: Scaffold a production-ready microservice with CI/CD, monitoring, and Kubernetes deployment
spec:
 owner: platform-team
 type: service

 parameters:
 - title: Service Details
 required:
 - name
 - owner
 properties:
 name:
 title: Service Name
 type: string
 pattern: '^[a-z0-9-]+$'
 owner:
 title: Owner Team
 type: string
 ui:field: OwnerPicker
 language:
 title: Language
 type: string
 enum: ['python', 'go', 'typescript', 'java']
 default: 'python'

 - title: Infrastructure
 properties:
 database:
 title: Database Type
 type: string
 enum: ['none', 'postgresql', 'mongodb', 'redis']
 scaling:
 title: Auto-scaling Profile
 type: string
 enum: ['small', 'medium', 'large']
 default: 'small'

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

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

 - id: provision-infra
 name: Provision Infrastructure
 action: http:backstage:request
 input:
 method: POST
 path: /api/terraform/provision
 body:
 service: $
 database: $
 scaling: $

 - id: register-catalog
 name: Register in Catalog
 action: catalog:register
 input:
 repoContentsUrl: $
 catalogInfoPath: '/catalog-info.yaml'
</code></pre></div><img src="https://images.unsplash.com/photo-1517694712202-14dd9538aa97?w=800" alt="Developer Working"> Photo by <a href="https://unsplash.com/@clemhlrdt">Clément Hélardot</a> on Unsplash<h3 id="3-infrastructure-abstraction-with-crossplane">3. Infrastructure Abstraction with Crossplane</h3>Abstract cloud resources into Kubernetes-native APIs:<div><pre><code># Define a composite resource
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
 name: databases.platform.myorg.com
spec:
 group: platform.myorg.com
 names:
 kind: Database
 plural: databases
 versions:
 - name: v1
 served: true
 referenceable: true
 schema:
 openAPIV3Schema:
 type: object
 properties:
 spec:
 type: object
 properties:
 size:
 type: string
 enum: ["small", "medium", "large"]
 engine:
 type: string
 enum: ["postgresql", "mysql"]
 required:
 - size
 - engine
---
# Developer just needs this:
apiVersion: platform.myorg.com/v1
kind: Database
metadata:
 name: user-db
spec:
 size: medium
 engine: postgresql
</code></pre></div><h3 id="4-gitops-with-argo-cd">4. GitOps with Argo CD</h3><div><pre><code># Application definition
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: payment-service
 namespace: argocd
spec:
 project: default
 source:
 repoURL: https://github.com/myorg/payment-service
 targetRevision: main
 path: kubernetes/overlays/production
 destination:
 server: https://kubernetes.default.svc
 namespace: payments
 syncPolicy:
 automated:
 prune: true
 selfHeal: true
 syncOptions:
 - CreateNamespace=true
</code></pre></div><h2 id="measuring-platform-success">Measuring Platform Success</h2><h3 id="dora-metrics">DORA Metrics</h3><div><pre><code># Track platform impact on delivery performance
from dataclasses import dataclass
from datetime import timedelta

@dataclass
class DORAMetrics:
 deployment_frequency: float # deploys per day
 lead_time: timedelta # commit to production
 change_failure_rate: float # % of deployments causing incidents
 time_to_restore: timedelta # incident to resolution

# Platform goals
ELITE_PERFORMANCE = DORAMetrics(
 deployment_frequency=1.0, # multiple deploys per day
 lead_time=timedelta(hours=1), # less than 1 hour
 change_failure_rate=0.05, # less than 5%
 time_to_restore=timedelta(hours=1) # less than 1 hour
)
</code></pre></div><h3 id="developer-satisfaction-devex">Developer Satisfaction (DevEx)</h3>Track these signals:<ul><li>Time from idea to production</li><li>Number of tools developers need to learn</li><li>Self-service success rate</li><li>Support ticket volume</li></ul><h2 id="common-anti-patterns">Common Anti-Patterns</h2><h3 id="1-the-ticket-platform">1. The “Ticket Platform”</h3><div><pre><code>❌ Developer wants to deploy
 → Opens ticket
 → Platform team provisions
 → 3 days later: deployed

✅ Developer wants to deploy
 → Uses self-service portal
 → Automated provisioning
 → 5 minutes later: deployed
</code></pre></div><h3 id="2-over-abstraction">2. Over-Abstraction</h3>Don’t hide everything:<div><pre><code>❌ Magic black box that "just works" until it doesn't

✅ Sensible defaults with escape hatches
 - Default config works for 80% of cases
 - Power users can customize when needed
 - Clear documentation for both paths
</code></pre></div><h3 id="3-building-everything-in-house">3. Building Everything In-House</h3>Adopt, then adapt:<table><thead><tr><th>Need</th><th>Build</th><th>Buy/Adopt</th></tr></thead><tbody><tr><td>Service Catalog</td><td>❌</td><td>Backstage</td></tr><tr><td>GitOps</td><td>❌</td><td>Argo CD / Flux</td></tr><tr><td>Infrastructure Abstraction</td><td>❌</td><td>Crossplane</td></tr><tr><td>Custom Workflows</td><td>✅</td><td>-</td></tr><tr><td>Domain-Specific Tools</td><td>✅</td><td>-</td></tr></tbody></table><h2 id="platform-team-structure">Platform Team Structure</h2><div><pre><code>Platform Team (6-10 engineers)
├── Infrastructure Core
│ ├── Kubernetes / Cloud experts
│ └── Security / Compliance
├── Developer Experience
│ ├── Portal / UI development
│ └── Documentation / Enablement
└── Automation &amp; Integration
 ├── CI/CD pipelines
 └── Observability stack
</code></pre></div><h2 id="getting-started-the-minimum-viable-platform">Getting Started: The Minimum Viable Platform</h2>Start small:<ol><li>Week 1-2: Service catalog (even a spreadsheet)</li><li>Week 3-4: One golden path template</li><li>Month 2: Automated deployments for one team</li><li>Month 3: Self-service infrastructure (one resource type)</li><li>Month 4+: Iterate based on feedback</li></ol><h2 id="conclusion">Conclusion</h2>Platform Engineering isn’t about buying a product or installing a tool. It’s a mindset shift: treating your internal infrastructure as a product, with developers as customers.The best platform is invisible. Developers don’t think about Kubernetes—they think about shipping features. That’s the goal.<hr>How is your organization approaching Platform Engineering? Share your journey in the comments. <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

Platform Engineering: The Evolution Beyond DevOps
DevOps promised developer empowerment. But somewhere along the way, “you build it, you run it” became “you build it, you configure the CI pipeline, manage the Kubernetes manifests, handle the monitoring, deal with the incidents, and also run it.”
Platform Engineering is the course correction.
Photo by Taylor Vick on Unsplash
The Problem with “Full Stack DevOps”
A typical modern application requires developers to understand:
Container orchestration (Kubernetes, ECS)
Infrastructure as Code (Terraform, Pulumi)
CI/CD pipelines (GitHub Actions, GitLab CI)
Observability (Prometheus, Grafana, OpenTelemetry)
Service mesh (Istio, Linkerd)
Secrets management (Vault, AWS Secrets Manager)
Database operations
Security compliance
That’s not empowerment—it’s cognitive overload.
What is Platform Engineering?
Platform Engineering treats the platform as a product, with developers as customers. The goal: golden paths that make the right thing the easy thing.
Traditional DevOps:
Developer → Learn Kubernetes → Configure Helm → Set up monitoring → Deploy
Platform Engineering:
Developer → Create service in portal → Deploy
(Platform team handles the complexity underneath)
Building Your Internal Developer Platform (IDP)
The Five Planes Model
┌─────────────────────────────────────────────┐
│           Developer Portal (UI)             │
├─────────────────────────────────────────────┤
│        Service Catalog & Templates          │
├─────────────────────────────────────────────┤
│      Automation & Orchestration Layer       │
├─────────────────────────────────────────────┤
│         Infrastructure Abstraction          │
├─────────────────────────────────────────────┤
│           Cloud Resources Layer             │
└─────────────────────────────────────────────┘
1. Developer Portal with Backstage
// catalog-info.yaml - Service Definition
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: Handles payment processing
  annotations:
    github.com/project-slug: myorg/payment-service
    backstage.io/kubernetes-id: payment-service
    pagerduty.com/service-id: PXXXXXX
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: checkout-system
  providesApis:
    - payment-api
  dependsOn:
    - component:user-service
    - resource:payments-db
2. Self-Service Templates
# scaffolder-template.yaml
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: microservice-template
  title: Create New Microservice
  description: Scaffold a production-ready microservice with CI/CD, monitoring, and Kubernetes deployment
spec:
  owner: platform-team
  type: service
  parameters:
    - title: Service Details
      required:
        - name
        - owner
      properties:
        name:
          title: Service Name
          type: string
          pattern: '^[a-z0-9-]+$'
        owner:
          title: Owner Team
          type: string
          ui:field: OwnerPicker
        language:
          title: Language
          type: string
          enum: ['python', 'go', 'typescript', 'java']
          default: 'python'
    - title: Infrastructure
      properties:
        database:
          title: Database Type
          type: string
          enum: ['none', 'postgresql', 'mongodb', 'redis']
        scaling:
          title: Auto-scaling Profile
          type: string
          enum: ['small', 'medium', 'large']
          default: 'small'
  steps:
    - id: fetch-base
      name: Fetch Base Template
      action: fetch:template
      input:
        url: ./skeleton/$
        values:
          name: $
          owner: $
    - id: create-repo
      name: Create GitHub Repository
      action: publish:github
      input:
        repoUrl: github.com?owner=myorg&repo=$
        defaultBranch: main
    - id: provision-infra
      name: Provision Infrastructure
      action: http:backstage:request
      input:
        method: POST
        path: /api/terraform/provision
        body:
          service: $
          database: $
          scaling: $
    - id: register-catalog
      name: Register in Catalog
      action: catalog:register
      input:
        repoContentsUrl: $
        catalogInfoPath: '/catalog-info.yaml'
Photo by Clément Hélardot on Unsplash
3. Infrastructure Abstraction with Crossplane
Abstract cloud resources into Kubernetes-native APIs:
# Define a composite resource
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: databases.platform.myorg.com
spec:
  group: platform.myorg.com
  names:
    kind: Database
    plural: databases
  versions:
    - name: v1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                size:
                  type: string
                  enum: ["small", "medium", "large"]
                engine:
                  type: string
                  enum: ["postgresql", "mysql"]
              required:
                - size
                - engine
---
# Developer just needs this:
apiVersion: platform.myorg.com/v1
kind: Database
metadata:
  name: user-db
spec:
  size: medium
  engine: postgresql
4. GitOps with Argo CD
# Application definition
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payment-service
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/payment-service
    targetRevision: main
    path: kubernetes/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: payments
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
Measuring Platform Success
DORA Metrics
# Track platform impact on delivery performance
from dataclasses import dataclass
from datetime import timedelta
@dataclass
class DORAMetrics:
    deployment_frequency: float  # deploys per day
    lead_time: timedelta         # commit to production
    change_failure_rate: float   # % of deployments causing incidents
    time_to_restore: timedelta   # incident to resolution
# Platform goals
ELITE_PERFORMANCE = DORAMetrics(
    deployment_frequency=1.0,        # multiple deploys per day
    lead_time=timedelta(hours=1),    # less than 1 hour
    change_failure_rate=0.05,        # less than 5%
    time_to_restore=timedelta(hours=1)  # less than 1 hour
)
Developer Satisfaction (DevEx)
Track these signals:
Time from idea to production
Number of tools developers need to learn
Self-service success rate
Support ticket volume
Common Anti-Patterns
1. The “Ticket Platform”
❌ Developer wants to deploy
   → Opens ticket
   → Platform team provisions
   → 3 days later: deployed
✅ Developer wants to deploy
   → Uses self-service portal
   → Automated provisioning
   → 5 minutes later: deployed
2. Over-Abstraction
Don’t hide everything:
❌ Magic black box that "just works" until it doesn't
✅ Sensible defaults with escape hatches
   - Default config works for 80% of cases
   - Power users can customize when needed
   - Clear documentation for both paths
3. Building Everything In-House
Adopt, then adapt:
Need
      Build
      Buy/Adopt
    
Service Catalog
      ❌
      Backstage
    
GitOps
      ❌
      Argo CD / Flux
    
Infrastructure Abstraction
      ❌
      Crossplane
    
Custom Workflows
      ✅
      -
    
Domain-Specific Tools
      ✅
      -
    
Platform Team Structure
Platform Team (6-10 engineers)
├── Infrastructure Core
│   ├── Kubernetes / Cloud experts
│   └── Security / Compliance
├── Developer Experience
│   ├── Portal / UI development
│   └── Documentation / Enablement
└── Automation & Integration
    ├── CI/CD pipelines
    └── Observability stack
Getting Started: The Minimum Viable Platform
Start small:
Week 1-2: Service catalog (even a spreadsheet)
Week 3-4: One golden path template
Month 2: Automated deployments for one team
Month 3: Self-service infrastructure (one resource type)
Month 4+: Iterate based on feedback
Conclusion
Platform Engineering isn’t about buying a product or installing a tool. It’s a mindset shift: treating your internal infrastructure as a product, with developers as customers.
The best platform is invisible. Developers don’t think about Kubernetes—they think about shipping features. That’s the goal.
How is your organization approaching Platform Engineering? Share your journey in the comments.

Platform Engineering: The Evolution Beyond DevOps

댓글