<div id="readability-page-1" class="page"><div><p><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=1200"></p><p>Platform engineering emerged as the hype successor to DevOps around 2023. The pitch: instead of every team managing their own infrastructure and pipelines, build a centralized Internal Developer Platform (IDP) that abstracts the complexity away. Give developers a self-service experience. Let them deploy without knowing Kubernetes.</p><p>Three years later, the hype has matured into something more nuanced. Some teams built IDPs that genuinely transformed their engineering culture. Others built elaborate internal tools that nobody wanted to use. The difference isn’t budget or tooling — it’s a set of mindset and execution choices.</p><p>This is what separates the IDPs developers love from the ones they route around.</p><p><img src="https://images.unsplash.com/photo-1531498860502-7c67cf02f657?w=800" alt="Developers collaborating around a whiteboard with sticky notes and diagrams"> <em>Photo by Marvin Meyer on Unsplash</em></p><hr><h2 id="what-an-idp-actually-is-and-isnt">What an IDP Actually Is (and Isn’t)</h2><p>Let’s start with clarity. An Internal Developer Platform is:</p><ul><li>A <strong>set of self-service capabilities</strong> that teams use to build, deploy, and operate software</li><li>Backed by <strong>automated systems</strong> that provision infrastructure, manage pipelines, and enforce standards</li><li>Designed around <strong>developer workflows</strong>, not infrastructure abstractions</li></ul><p>It is <strong>not</strong>:</p><ul><li>Just a deployment pipeline</li><li>A portal that wraps Kubernetes with a UI</li><li>Infrastructure-as-code templates bundled together</li><li>A ticketing system with a friendlier interface</li></ul><p>The platform engineering team’s job is to be a <strong>product team</strong> whose product is the development experience. Their customers are internal developers. They have PMs, they do user research, they measure adoption, they iterate on feedback.</p><hr><h2 id="the-five-capabilities-every-good-idp-has">The Five Capabilities Every Good IDP Has</h2><p>After studying teams that successfully built IDPs in the 2023-2025 wave, five core capabilities consistently appear in the ones developers actually adopt:</p><h3 id="1-self-service-environments">1. Self-Service Environments</h3><p>Developers can create a complete running environment — with their app, dependencies, databases, and services — without filing a ticket or waiting for an ops team.</p><p>This means:</p><ul><li>Ephemeral environments per pull request</li><li>Preview environments with real data subsets</li><li>One-click “clone production config” for local dev</li></ul><div><pre><code><span># Developer runs: platform env create --template service-with-postgres</span>
<span># Platform provisions:</span>
<span>environment</span><span>:</span>
  <span>name</span><span>:</span> <span>feature-auth-refactor-pr-142</span>
  <span>services</span><span>:</span>
    <span>-</span> <span>name</span><span>:</span> <span>my-service</span>
      <span>image</span><span>:</span> <span>registry.internal/my-service:pr-142</span>
      <span>replicas</span><span>:</span> <span>1</span>
    <span>-</span> <span>name</span><span>:</span> <span>postgres</span>
      <span>template</span><span>:</span> <span>postgres-16-dev</span>
      <span>seed</span><span>:</span> <span>last-7-days-anonymized</span>
  <span>lifetime</span><span>:</span> <span>7d</span>
  <span>auto-extend-on-push</span><span>:</span> <span>true</span>
</code></pre></div><p>The provisioning should take <strong>under 3 minutes</strong> for a standard service environment. If it takes longer, developers stop using it.</p><h3 id="2-golden-paths-not-golden-cages">2. Golden Paths (Not Golden Cages)</h3><p>A “golden path” is a paved, opinionated route for the most common workflows: starting a new service, adding a background job, deploying to production. Walking the golden path should be <strong>fast, safe, and require no expertise in the underlying infrastructure</strong>.</p><p>But here’s where many platforms fail: they make the golden path the <strong>only</strong> path. When developers have legitimate reasons to deviate — a service with unusual requirements, an experiment, a migration — they hit walls.</p><p>Good IDPs are opinionated but escapable. The platform provides guardrails, not a cage. Deviation should be possible, documented, and not require platform team approval for every case.</p><h3 id="3-integrated-observability">3. Integrated Observability</h3><p>Developers shouldn’t need to navigate five different dashboards to understand what their service is doing. The platform should surface:</p><ul><li>Metrics (latency, error rate, throughput)</li><li>Logs (structured, searchable, correlated)</li><li>Traces (distributed, linked to logs)</li><li>Alerts (pre-configured sensible defaults, customizable)</li></ul><p>All linked to the service, all accessible from the same place. The developer deploys a service and observability appears automatically — no instrumentation tickets, no manual Grafana dashboard creation.</p><h3 id="4-deployment-workflows-with-built-in-safety">4. Deployment Workflows with Built-in Safety</h3><p>The deployment experience should be:</p><div><pre><code>git push → CI runs → staging auto-deploys → one-click promote to prod
</code></pre></div><p>With guardrails at each step:</p><ul><li>Required checks (tests, security scan, review)</li><li>Automatic rollback triggers (error rate spike, latency increase)</li><li>Progressive rollout (canary → 10% → 50% → 100%)</li><li>Clear rollback command</li></ul><div><pre><code><span># Promote to production</span>
platform deploy promote <span>--service</span> my-service <span>--from</span> staging <span>--to</span> prod

<span># Output:</span>
<span># ✓ Health checks passing on staging (99.8% success rate, p99 45ms)</span>
<span># ✓ Security scan: 0 critical/high issues</span>
<span># ✓ 2 approvals received</span>
<span># Deploying with 10% canary → 30min → full rollout</span>
<span># Monitor: https://platform.internal/deploy/abc123</span>
</code></pre></div><h3 id="5-service-catalog-and-documentation">5. Service Catalog and Documentation</h3><p>As the platform scales, discoverability becomes critical. The service catalog answers:</p><ul><li>What services exist?</li><li>Who owns this service?</li><li>How do I call this API?</li><li>What’s the on-call rotation?</li><li>What does this service depend on?</li></ul><p>Backstage (now Backstage 2.0) is the standard open-source foundation here. The key is keeping it <strong>automatically populated</strong> — if developers have to manually update the catalog, it will be stale within weeks.</p><hr><h2 id="the-adoption-anti-patterns">The Adoption Anti-Patterns</h2><p>Most IDP failures trace back to one of these patterns:</p><p><img src="https://images.unsplash.com/photo-1543269664-56d93c1b41a6?w=800" alt="Person looking frustrated at a complex screen full of code and dashboards"> <em>Photo by Tim Gouw on Unsplash</em></p><h3 id="the-build-it-and-they-will-come-mistake">The “Build It and They Will Come” Mistake</h3><p>Platform teams that spend 18 months building in isolation, then launch expecting enthusiastic adoption, are almost always disappointed. Developers don’t trust systems they weren’t involved in designing.</p><p><strong>Fix</strong>: Ship something tiny after 6 weeks. Get 2-3 pilot teams using it in anger. Let their friction shape the platform before you generalize.</p><h3 id="optimizing-for-infrastructure-not-developer-workflows">Optimizing for Infrastructure, Not Developer Workflows</h3><p>“Our platform makes it easy to configure Kubernetes” is not a compelling developer experience. Developers don’t care about Kubernetes. They care about deploying their service and having it work.</p><p>The platform should abstract infrastructure entirely. A developer should be able to use the platform effectively without knowing whether it’s running on EKS, GKE, or bare metal.</p><h3 id="measuring-tickets-closed-instead-of-developer-joy">Measuring Tickets Closed Instead of Developer Joy</h3><p>If your platform team is measuring “infrastructure tickets resolved,” you’re measuring the wrong thing. Measure:</p><ul><li>Time from code merge to production deployment (should drop)</li><li>Time to provision a new service from zero (should be &lt; 1 day)</li><li>Developer satisfaction score (run quarterly surveys)</li><li>Platform adoption rate across teams</li></ul><h3 id="making-customization-require-platform-team-involvement">Making Customization Require Platform Team Involvement</h3><p>If every deviation from the golden path requires a Jira ticket to the platform team, you’ve built a bureaucracy, not a platform. Developers will route around it with their own Terraform scripts and shell scripts.</p><hr><h2 id="the-technology-stack-in-2026">The Technology Stack in 2026</h2><p>The platform engineering toolchain has consolidated significantly:</p><table><thead><tr><th>Layer</th><th>Options</th><th>Recommendation</th></tr></thead><tbody><tr><td><strong>Orchestration</strong></td><td>Kubernetes, Nomad</td><td>Kubernetes (accept the complexity)</td></tr><tr><td><strong>Developer Portal</strong></td><td>Backstage, Port, Cortex</td><td>Backstage for open-source; Port for managed</td></tr><tr><td><strong>GitOps</strong></td><td>ArgoCD, Flux</td><td>ArgoCD (better UI, operator model)</td></tr><tr><td><strong>Service Mesh</strong></td><td>Istio, Cilium, Linkerd</td><td>Cilium (eBPF-based, lower overhead)</td></tr><tr><td><strong>Secrets</strong></td><td>Vault, AWS Secrets Manager</td><td>Vault (cloud-agnostic) or cloud-native if single cloud</td></tr><tr><td><strong>Observability</strong></td><td>LGTM stack, Datadog, Honeycomb</td><td>LGTM (Loki+Grafana+Tempo+Mimir) for self-hosted</td></tr><tr><td><strong>CI/CD</strong></td><td>GitHub Actions, Tekton, Dagger</td><td>GitHub Actions + Dagger for portability</td></tr></tbody></table><p>The biggest shift in 2025-2026: <strong>Dagger</strong> has become the standard for portable CI/CD logic. Instead of YAML pipelines tied to a specific CI system, you write pipeline logic in Go/Python/TypeScript that runs identically locally, in GitHub Actions, and in your private runners.</p><hr><h2 id="building-a-team-platform-engineering-vs-devops-vs-sre">Building a Team: Platform Engineering vs. DevOps vs. SRE</h2><p>One persistent confusion: what’s the difference between platform engineering, DevOps, and SRE?</p><p><strong>DevOps</strong> (philosophy): Break down silos between dev and ops. Everyone is responsible for reliability. Culture shift, not a job title.</p><p><strong>SRE</strong> (discipline): Treat operations as a software problem. Error budgets, SLOs, toil reduction. Focused on reliability.</p><p><strong>Platform Engineering</strong> (team): Build internal products that let developers self-serve. Focused on developer experience and productivity.</p><p>A mature engineering org has all three perspectives. The platform team builds and operates the IDP. SRE principles govern how reliability is managed within it. DevOps culture means developers take ownership of their services running on the platform.</p><hr><h2 id="where-to-start-a-90-day-plan">Where to Start: A 90-Day Plan</h2><p>If you’re starting a platform engineering initiative today:</p><p><strong>Days 1-30: Discovery</strong></p><ul><li>Shadow 5 different developers for half a day each</li><li>Document every manual, repetitive task you observe</li><li>Identify the 3 biggest pain points (usually: environment setup, deployment toil, observability fragmentation)</li><li>Pick ONE to solve first</li></ul><p><strong>Days 31-60: Build and Pilot</strong></p><ul><li>Build the simplest possible solution to the top pain point</li><li>Deploy it with 2 pilot teams</li><li>Collect feedback weekly</li><li>Don’t build anything else until pilots are happy</li></ul><p><strong>Days 61-90: Generalize and Document</strong></p><ul><li>Make it work for 5 more teams</li><li>Write documentation <em>based on questions you’ve been asked</em></li><li>Set up basic metrics (adoption, usage, errors)</li><li>Plan the next pain point to tackle</li></ul><p>The temptation to build everything at once is strong. Resist it. Platform engineering is a product discipline — ship, learn, iterate.</p><hr><h2 id="the-bottom-line">The Bottom Line</h2><p>Platform engineering done right is one of the highest-leverage investments an engineering organization can make. When developers can self-serve environments, deploy safely, and observe their services without friction — that’s flow state at an organizational scale.</p><p>But the graveyard of “internal platforms that nobody uses” is full of technically excellent tools that missed the human element. The platform is a product. Developers are customers. Treat them as such.</p><p>Build the golden path. Make it easy to use. Make it easy to escape. Measure what developers actually experience, not what you build. And never stop talking to the people you’re building for. <br></p><div><p>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </p></div></div></div>

Dev Note

Platform engineering emerged as the hype successor to DevOps around 2023. The pitch: instead of every team managing their own infrastructure and pipelines, build a centralized Internal Developer Platform (IDP) that abstracts the complexity away. Give developers a self-service experience. Let them deploy without knowing Kubernetes.
Three years later, the hype has matured into something more nuanced. Some teams built IDPs that genuinely transformed their engineering culture. Others built elaborate internal tools that nobody wanted to use. The difference isn’t budget or tooling — it’s a set of mindset and execution choices.
This is what separates the IDPs developers love from the ones they route around.
Photo by Marvin Meyer on Unsplash
What an IDP Actually Is (and Isn’t)
Let’s start with clarity. An Internal Developer Platform is:
A set of self-service capabilities that teams use to build, deploy, and operate software
Backed by automated systems that provision infrastructure, manage pipelines, and enforce standards
Designed around developer workflows, not infrastructure abstractions
It is not:
Just a deployment pipeline
A portal that wraps Kubernetes with a UI
Infrastructure-as-code templates bundled together
A ticketing system with a friendlier interface
The platform engineering team’s job is to be a product team whose product is the development experience. Their customers are internal developers. They have PMs, they do user research, they measure adoption, they iterate on feedback.
The Five Capabilities Every Good IDP Has
After studying teams that successfully built IDPs in the 2023-2025 wave, five core capabilities consistently appear in the ones developers actually adopt:
1. Self-Service Environments
Developers can create a complete running environment — with their app, dependencies, databases, and services — without filing a ticket or waiting for an ops team.
This means:
Ephemeral environments per pull request
Preview environments with real data subsets
One-click “clone production config” for local dev
# Developer runs: platform env create --template service-with-postgres
# Platform provisions:
environment:
  name: feature-auth-refactor-pr-142
  services:
    - name: my-service
      image: registry.internal/my-service:pr-142
      replicas: 1
    - name: postgres
      template: postgres-16-dev
      seed: last-7-days-anonymized
  lifetime: 7d
  auto-extend-on-push: true
The provisioning should take under 3 minutes for a standard service environment. If it takes longer, developers stop using it.
2. Golden Paths (Not Golden Cages)
A “golden path” is a paved, opinionated route for the most common workflows: starting a new service, adding a background job, deploying to production. Walking the golden path should be fast, safe, and require no expertise in the underlying infrastructure.
But here’s where many platforms fail: they make the golden path the only path. When developers have legitimate reasons to deviate — a service with unusual requirements, an experiment, a migration — they hit walls.
Good IDPs are opinionated but escapable. The platform provides guardrails, not a cage. Deviation should be possible, documented, and not require platform team approval for every case.
3. Integrated Observability
Developers shouldn’t need to navigate five different dashboards to understand what their service is doing. The platform should surface:
Metrics (latency, error rate, throughput)
Logs (structured, searchable, correlated)
Traces (distributed, linked to logs)
Alerts (pre-configured sensible defaults, customizable)
All linked to the service, all accessible from the same place. The developer deploys a service and observability appears automatically — no instrumentation tickets, no manual Grafana dashboard creation.
4. Deployment Workflows with Built-in Safety
The deployment experience should be:
git push → CI runs → staging auto-deploys → one-click promote to prod
With guardrails at each step:
Required checks (tests, security scan, review)
Automatic rollback triggers (error rate spike, latency increase)
Progressive rollout (canary → 10% → 50% → 100%)
Clear rollback command
# Promote to production
platform deploy promote --service my-service --from staging --to prod
# Output:
# ✓ Health checks passing on staging (99.8% success rate, p99 45ms)
# ✓ Security scan: 0 critical/high issues
# ✓ 2 approvals received
# Deploying with 10% canary → 30min → full rollout
# Monitor: https://platform.internal/deploy/abc123
5. Service Catalog and Documentation
As the platform scales, discoverability becomes critical. The service catalog answers:
What services exist?
Who owns this service?
How do I call this API?
What’s the on-call rotation?
What does this service depend on?
Backstage (now Backstage 2.0) is the standard open-source foundation here. The key is keeping it automatically populated — if developers have to manually update the catalog, it will be stale within weeks.
The Adoption Anti-Patterns
Most IDP failures trace back to one of these patterns:
Photo by Tim Gouw on Unsplash
The “Build It and They Will Come” Mistake
Platform teams that spend 18 months building in isolation, then launch expecting enthusiastic adoption, are almost always disappointed. Developers don’t trust systems they weren’t involved in designing.
Fix: Ship something tiny after 6 weeks. Get 2-3 pilot teams using it in anger. Let their friction shape the platform before you generalize.
Optimizing for Infrastructure, Not Developer Workflows
“Our platform makes it easy to configure Kubernetes” is not a compelling developer experience. Developers don’t care about Kubernetes. They care about deploying their service and having it work.
The platform should abstract infrastructure entirely. A developer should be able to use the platform effectively without knowing whether it’s running on EKS, GKE, or bare metal.
Measuring Tickets Closed Instead of Developer Joy
If your platform team is measuring “infrastructure tickets resolved,” you’re measuring the wrong thing. Measure:
Time from code merge to production deployment (should drop)
Time to provision a new service from zero (should be < 1 day)
Developer satisfaction score (run quarterly surveys)
Platform adoption rate across teams
Making Customization Require Platform Team Involvement
If every deviation from the golden path requires a Jira ticket to the platform team, you’ve built a bureaucracy, not a platform. Developers will route around it with their own Terraform scripts and shell scripts.
The Technology Stack in 2026
The platform engineering toolchain has consolidated significantly:
Layer
      Options
      Recommendation
    
Orchestration
      Kubernetes, Nomad
      Kubernetes (accept the complexity)
    
Developer Portal
      Backstage, Port, Cortex
      Backstage for open-source; Port for managed
    
GitOps
      ArgoCD, Flux
      ArgoCD (better UI, operator model)
    
Service Mesh
      Istio, Cilium, Linkerd
      Cilium (eBPF-based, lower overhead)
    
Secrets
      Vault, AWS Secrets Manager
      Vault (cloud-agnostic) or cloud-native if single cloud
    
Observability
      LGTM stack, Datadog, Honeycomb
      LGTM (Loki+Grafana+Tempo+Mimir) for self-hosted
    
CI/CD
      GitHub Actions, Tekton, Dagger
      GitHub Actions + Dagger for portability
    
The biggest shift in 2025-2026: Dagger has become the standard for portable CI/CD logic. Instead of YAML pipelines tied to a specific CI system, you write pipeline logic in Go/Python/TypeScript that runs identically locally, in GitHub Actions, and in your private runners.
Building a Team: Platform Engineering vs. DevOps vs. SRE
One persistent confusion: what’s the difference between platform engineering, DevOps, and SRE?
DevOps (philosophy): Break down silos between dev and ops. Everyone is responsible for reliability. Culture shift, not a job title.
SRE (discipline): Treat operations as a software problem. Error budgets, SLOs, toil reduction. Focused on reliability.
Platform Engineering (team): Build internal products that let developers self-serve. Focused on developer experience and productivity.
A mature engineering org has all three perspectives. The platform team builds and operates the IDP. SRE principles govern how reliability is managed within it. DevOps culture means developers take ownership of their services running on the platform.
Where to Start: A 90-Day Plan
If you’re starting a platform engineering initiative today:
Days 1-30: Discovery
Shadow 5 different developers for half a day each
Document every manual, repetitive task you observe
Identify the 3 biggest pain points (usually: environment setup, deployment toil, observability fragmentation)
Pick ONE to solve first
Days 31-60: Build and Pilot
Build the simplest possible solution to the top pain point
Deploy it with 2 pilot teams
Collect feedback weekly
Don’t build anything else until pilots are happy
Days 61-90: Generalize and Document
Make it work for 5 more teams
Write documentation based on questions you’ve been asked
Set up basic metrics (adoption, usage, errors)
Plan the next pain point to tackle
The temptation to build everything at once is strong. Resist it. Platform engineering is a product discipline — ship, learn, iterate.
The Bottom Line
Platform engineering done right is one of the highest-leverage investments an engineering organization can make. When developers can self-serve environments, deploy safely, and observe their services without friction — that’s flow state at an organizational scale.
But the graveyard of “internal platforms that nobody uses” is full of technically excellent tools that missed the human element. The platform is a product. Developers are customers. Treat them as such.
Build the golden path. Make it easy to use. Make it easy to escape. Measure what developers actually experience, not what you build. And never stop talking to the people you’re building for.

Platform Engineering in 2026: How to Build an Internal Developer Platform That Developers Actually Use

댓글