<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1522071820081-009f0129c71c?w=1200&amp;q=80"><h2 id="the-platform-engineering-hype-cycle-is-over--now-comes-the-work">The Platform Engineering Hype Cycle Is Over — Now Comes the Work</h2>Gartner predicted platform engineering would be mainstream by 2026. They were right. But “mainstream” doesn’t mean “done right.” Most companies now have a platform team. Far fewer have a platform that developers actually want to use.The gap between “we have an IDP” and “developers love our IDP” is where platform engineering value is either created or destroyed.This post is about closing that gap.<img src="https://images.unsplash.com/photo-1553877522-43269d4ea984?w=800&amp;q=80" alt="Team collaborating in a modern office"> Photo by Marvin Meyer on Unsplash<hr><h2 id="what-is-an-internal-developer-platform-actually">What Is an Internal Developer Platform, Actually?</h2>An IDP is the curated set of tools, services, and workflows that lets product engineers ship software without becoming infrastructure experts.The operative word: curated. Not every tool. Not self-serve Kubernetes for its own sake. A thoughtfully assembled system that removes accidental complexity while preserving essential complexity.A mature IDP covers:<div><pre><code>Developer → Platform Interface
├── Service Catalog (what exists, who owns it)
├── Self-Service Provisioning (new services, environments, databases)
├── CI/CD (standardized pipelines, no reinventing the wheel)
├── Observability (logs, metrics, traces — out of the box)
├── Security Policies (enforced automatically, not manually)
└── Documentation (auto-generated where possible)
</code></pre></div><hr><h2 id="the-three-laws-of-platform-engineering">The Three Laws of Platform Engineering</h2>After watching dozens of IDP projects succeed and fail, three laws consistently separate good from bad:<h3 id="law-1-the-platform-is-a-product">Law 1: The Platform Is a Product</h3>Your customers are internal developers. Treat them like customers.<ul><li>Run user research. Talk to the teams using your platform.</li><li>Measure adoption, not just availability.</li><li>Have a product backlog, not just a Jira board of tech debt.</li><li>Define success in terms of developer outcomes: deploy frequency, lead time, failure rate.</li></ul>A platform nobody uses is just infrastructure theater.<h3 id="law-2-pave-the-golden-path-dont-mandate-it">Law 2: Pave the Golden Path, Don’t Mandate It</h3>The golden path is the opinionated, supported, optimized way to do things. It should be:<ul><li>The path of least resistance — easier than doing it yourself</li><li>Not mandatory — teams can escape when they have good reason</li><li>Well-documented — the why, not just the how</li></ul>Force developers onto your platform and they’ll route around it. Make the platform genuinely easier and they’ll choose it.<h3 id="law-3-reduce-cognitive-load-not-control">Law 3: Reduce Cognitive Load, Not Control</h3>The point of a platform isn’t to control what engineers do. It’s to reduce the cognitive load of doing it.Cognitive load = mental effort required to ship software.Every decision a developer shouldn’t have to make (what observability stack? which secret manager? how to set up TLS?) is cognitive load you can absorb into the platform.<hr><h2 id="backstage-in-2026-the-ecosystem-has-won">Backstage in 2026: The Ecosystem Has Won</h2><a href="https://backstage.io/">Backstage</a> is now the undisputed foundation for service catalogs and developer portals. With 1000+ plugins and adoption at Spotify, Netflix, American Airlines, and thousands of others, the ecosystem question is settled.What’s changed in 2026:<h3 id="backstage-plugins-worth-installing">Backstage Plugins Worth Installing</h3><div><pre><code># Catalog essentials
@backstage/plugin-catalog # Core catalog
@backstage/plugin-catalog-backend # Backend APIs
@backstage/plugin-techdocs # Auto-generated docs

# Developer workflow
@backstage/plugin-scaffolder # Service templates
@backstage/plugin-cicd-statistics # Pipeline insights

# Observability
@backstage/plugin-kubernetes # K8s cluster view
@roadiehq/backstage-plugin-datadog # Datadog integration

# Security
@roadiehq/backstage-plugin-security-insights # CVE tracking
</code></pre></div><h3 id="the-catalog-infoyaml-standard">The catalog-info.yaml Standard</h3>Every service, every repo gets this file:<div><pre><code>apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
 name: payment-service
 title: Payment Service
 description: Handles all payment processing for the platform
 tags:
 - java
 - payments
 - critical
 annotations:
 github.com/project-slug: myorg/payment-service
 backstage.io/techdocs-ref: dir:.
 pagerduty.com/service-id: PXXXXXX
spec:
 type: service
 lifecycle: production
 owner: payments-team
 system: checkout
 dependsOn:
 - component:order-service
 - resource:payments-db
 providesApis:
 - payment-api
</code></pre></div>This single file becomes the source of truth for ownership, dependencies, runbooks, and on-call routing.<hr><h2 id="self-service-provisioning-the-golden-path-in-action">Self-Service Provisioning: The Golden Path in Action</h2>The highest-value thing a platform team can build: one command to get a new service that’s fully configured, observed, and deployed.With Backstage scaffolding:<div><pre><code># Template definition
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
 name: new-service-template
 title: New Go Microservice
spec:
 parameters:
 - title: Service Details
 properties:
 serviceName:
 type: string
 team:
 type: string
 tier:
 enum: [critical, standard, dev]
 steps:
 - id: create-repo
 action: publish:github
 input:
 repoUrl: github.com?owner=myorg&amp;repo=$
 
 - id: apply-template
 action: fetch:template
 input:
 url: ./skeleton/go-service
 values:
 name: $
 team: $
 
 - id: register-catalog
 action: catalog:register
 input:
 catalogInfoPath: /catalog-info.yaml
 
 - id: setup-monitoring
 action: datadog:create-service
 input:
 name: $
 tier: $
</code></pre></div>Developer runs this template → gets a repo with CI/CD, observability, service catalog entry, PagerDuty integration, and runbook template. In 5 minutes. Without talking to platform team.<hr><h2 id="measuring-platform-success">Measuring Platform Success</h2>Stop measuring platform health by uptime. Measure it by DORA metrics across your engineering org:<table><thead><tr><th>Metric</th><th>Target</th><th>How Platform Helps</th></tr></thead><tbody><tr><td>Deployment Frequency</td><td>&gt; 1/day</td><td>Standardized CI/CD, easy rollbacks</td></tr><tr><td>Lead Time</td><td>&lt; 1 hour</td><td>Self-service provisioning, automated testing</td></tr><tr><td>Change Failure Rate</td><td>&lt; 5%</td><td>Policy enforcement, canary deploys</td></tr><tr><td>MTTR</td><td>&lt; 1 hour</td><td>Observability out-of-the-box, runbooks</td></tr></tbody></table>Instrument this in your platform. Surface it in Backstage. Let teams see how they’re trending.<hr><h2 id="the-anti-patterns-that-kill-platforms">The Anti-Patterns That Kill Platforms</h2>The “Just Use Kubernetes” Trap: Exposing raw Kubernetes to developers is not a platform. It’s infrastructure with extra steps. Abstract it.The Feature Factory Trap: Building features nobody asked for. Talk to developers first.The Top-Down Mandate: “Everyone must use the platform by Q3.” Mandates generate compliance, not adoption. Build something worth choosing.The Snowflake Exception Death Spiral: Every exception to the golden path becomes a maintenance burden. Either absorb it into the platform or document why it’s truly exceptional.<hr><h2 id="conclusion">Conclusion</h2>Platform engineering has matured from buzzword to discipline. The teams doing it well share a mindset: they’re building a product for internal customers, obsessing over developer experience, and measuring outcomes in shipping velocity — not infrastructure complexity.Build the golden path. Make it genuinely easier. Measure adoption. Iterate.That’s it. That’s platform engineering. <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

The Platform Engineering Hype Cycle Is Over — Now Comes the Work
Gartner predicted platform engineering would be mainstream by 2026. They were right. But “mainstream” doesn’t mean “done right.” Most companies now have a platform team. Far fewer have a platform that developers actually want to use.
The gap between “we have an IDP” and “developers love our IDP” is where platform engineering value is either created or destroyed.
This post is about closing that gap.
Photo by Marvin Meyer on Unsplash
What Is an Internal Developer Platform, Actually?
An IDP is the curated set of tools, services, and workflows that lets product engineers ship software without becoming infrastructure experts.
The operative word: curated. Not every tool. Not self-serve Kubernetes for its own sake. A thoughtfully assembled system that removes accidental complexity while preserving essential complexity.
A mature IDP covers:
Developer → Platform Interface
├── Service Catalog (what exists, who owns it)
├── Self-Service Provisioning (new services, environments, databases)
├── CI/CD (standardized pipelines, no reinventing the wheel)
├── Observability (logs, metrics, traces — out of the box)
├── Security Policies (enforced automatically, not manually)
└── Documentation (auto-generated where possible)
The Three Laws of Platform Engineering
After watching dozens of IDP projects succeed and fail, three laws consistently separate good from bad:
Law 1: The Platform Is a Product
Your customers are internal developers. Treat them like customers.
Run user research. Talk to the teams using your platform.
Measure adoption, not just availability.
Have a product backlog, not just a Jira board of tech debt.
Define success in terms of developer outcomes: deploy frequency, lead time, failure rate.
A platform nobody uses is just infrastructure theater.
Law 2: Pave the Golden Path, Don’t Mandate It
The golden path is the opinionated, supported, optimized way to do things. It should be:
The path of least resistance — easier than doing it yourself
Not mandatory — teams can escape when they have good reason
Well-documented — the why, not just the how
Force developers onto your platform and they’ll route around it. Make the platform genuinely easier and they’ll choose it.
Law 3: Reduce Cognitive Load, Not Control
The point of a platform isn’t to control what engineers do. It’s to reduce the cognitive load of doing it.
Cognitive load = mental effort required to ship software.
Every decision a developer shouldn’t have to make (what observability stack? which secret manager? how to set up TLS?) is cognitive load you can absorb into the platform.
Backstage in 2026: The Ecosystem Has Won
Backstage is now the undisputed foundation for service catalogs and developer portals. With 1000+ plugins and adoption at Spotify, Netflix, American Airlines, and thousands of others, the ecosystem question is settled.
What’s changed in 2026:
Backstage Plugins Worth Installing
# Catalog essentials
@backstage/plugin-catalog # Core catalog
@backstage/plugin-catalog-backend # Backend APIs
@backstage/plugin-techdocs # Auto-generated docs
# Developer workflow
@backstage/plugin-scaffolder # Service templates
@backstage/plugin-cicd-statistics # Pipeline insights
# Observability
@backstage/plugin-kubernetes # K8s cluster view
@roadiehq/backstage-plugin-datadog # Datadog integration
# Security
@roadiehq/backstage-plugin-security-insights # CVE tracking
The catalog-info.yaml Standard
Every service, every repo gets this file:
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
 name: payment-service
 title: Payment Service
 description: Handles all payment processing for the platform
 tags:
 - java
 - payments
 - critical
 annotations:
 github.com/project-slug: myorg/payment-service
 backstage.io/techdocs-ref: dir:.
 pagerduty.com/service-id: PXXXXXX
spec:
 type: service
 lifecycle: production
 owner: payments-team
 system: checkout
 dependsOn:
 - component:order-service
 - resource:payments-db
 providesApis:
 - payment-api
This single file becomes the source of truth for ownership, dependencies, runbooks, and on-call routing.
Self-Service Provisioning: The Golden Path in Action
The highest-value thing a platform team can build: one command to get a new service that’s fully configured, observed, and deployed.
With Backstage scaffolding:
# Template definition
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
 name: new-service-template
 title: New Go Microservice
spec:
 parameters:
 - title: Service Details
 properties:
 serviceName:
 type: string
 team:
 type: string
 tier:
 enum: [critical, standard, dev]
 steps:
 - id: create-repo
 action: publish:github
 input:
 repoUrl: github.com?owner=myorg&repo=$
 
 - id: apply-template
 action: fetch:template
 input:
 url: ./skeleton/go-service
 values:
 name: $
 team: $
 
 - id: register-catalog
 action: catalog:register
 input:
 catalogInfoPath: /catalog-info.yaml
 
 - id: setup-monitoring
 action: datadog:create-service
 input:
 name: $
 tier: $
Developer runs this template → gets a repo with CI/CD, observability, service catalog entry, PagerDuty integration, and runbook template. In 5 minutes. Without talking to platform team.
Measuring Platform Success
Stop measuring platform health by uptime. Measure it by DORA metrics across your engineering org:
Metric
 Target
 How Platform Helps
 
Deployment Frequency
 > 1/day
 Standardized CI/CD, easy rollbacks
 
Lead Time
 < 1 hour
 Self-service provisioning, automated testing
 
Change Failure Rate
 < 5%
 Policy enforcement, canary deploys
 
MTTR
 < 1 hour
 Observability out-of-the-box, runbooks
 
Instrument this in your platform. Surface it in Backstage. Let teams see how they’re trending.
The Anti-Patterns That Kill Platforms
The “Just Use Kubernetes” Trap: Exposing raw Kubernetes to developers is not a platform. It’s infrastructure with extra steps. Abstract it.
The Feature Factory Trap: Building features nobody asked for. Talk to developers first.
The Top-Down Mandate: “Everyone must use the platform by Q3.” Mandates generate compliance, not adoption. Build something worth choosing.
The Snowflake Exception Death Spiral: Every exception to the golden path becomes a maintenance burden. Either absorb it into the platform or document why it’s truly exceptional.
Conclusion
Platform engineering has matured from buzzword to discipline. The teams doing it well share a mindset: they’re building a product for internal customers, obsessing over developer experience, and measuring outcomes in shipping velocity — not infrastructure complexity.
Build the golden path. Make it genuinely easier. Measure adoption. Iterate.
That’s it. That’s platform engineering.

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

댓글