<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1504384308090-c894fdcc538d?w=1200">Platform engineering has become the dominant framing for infrastructure teams over the last two years. Virtually every mid-to-large engineering org now has a “platform team” or is building one. And yet, the pattern I see repeatedly: teams build sophisticated internal developer platforms (IDPs) that developers quietly ignore in favor of doing things manually or finding workarounds.Why? Because platform teams often optimize for completeness and compliance rather than developer experience. They build platforms that can do everything and that developers have to fight to use. This post is about the patterns that produce platforms developers actually adopt.<hr><h2 id="the-core-problem-cognitive-load-transfer">The Core Problem: Cognitive Load Transfer</h2>Platform engineering’s stated goal is to reduce cognitive load for application developers. But many IDPs simply transfer the cognitive load rather than eliminating it. Instead of thinking about Kubernetes YAML, developers now think about:<ul><li>A bespoke CLI with inconsistent flags and incomplete documentation</li><li>A portal that requires understanding the platform team’s mental model</li><li>Multi-step workflows that could be automated but aren’t</li><li>Abstractions that leak at precisely the wrong moments</li></ul>The platform should absorb complexity, not rename it.<hr><h2 id="what-good-platform-engineering-looks-like">What Good Platform Engineering Looks Like</h2>The best IDPs I’ve seen share a few characteristics:Golden paths, not golden cages. A golden path is the opinionated, well-maintained path that works for 80% of use cases and makes the right thing easy. A golden cage is a platform that forces everyone onto a single path, breaking when use cases diverge. Build the path, make it attractive, but provide escape hatches.Paved roads, not toll roads. Developers shouldn’t have to justify using the platform’s tools or ask for access. The default experience should be self-service.Thin abstractions. Every abstraction layer you add is a potential leak point. Prefer thin abstractions that compose well over thick ones that try to hide everything.<hr><h2 id="the-platform-engineering-stack-in-2026">The Platform Engineering Stack in 2026</h2><img src="https://images.unsplash.com/photo-1451187580459-43490279c0fa?w=800" alt="Modern cloud infrastructure overview"> Photo by NASA on UnsplashThe tooling has consolidated significantly. The emerging reference stack:Control Plane: Backstage + Crossplane<a href="https://backstage.io/">Backstage</a> has won the developer portal battle. It’s not perfect, but its plugin ecosystem and wide adoption mean you’re not building alone. In 2026, a Backstage instance with the right plugins can serve as:<ul><li>Service catalog</li><li>Software templates (scaffolding)</li><li>Infrastructure self-service</li><li>Documentation hub</li><li>Incident management portal</li></ul><a href="https://www.crossplane.io/">Crossplane</a> has become the standard for infrastructure composition. Define your infrastructure as Kubernetes CRDs, compose complex environments from simple building blocks, and let developers provision resources through the Kubernetes API they already know.<div><pre><code># A developer creates this Composite Resource — no Terraform knowledge needed
apiVersion: platform.company.com/v1alpha1
kind: AppEnvironment
metadata:
 name: payment-service-staging
spec:
 parameters:
 environment: staging
 region: us-east-1
 database:
 engine: postgresql
 size: medium
 cache:
 enabled: true
 size: small
 serviceAccount:
 externalSecrets: true
</code></pre></div>The platform team defines the XRD (Composite Resource Definition) and composition. The developer only sees the AppEnvironment abstraction. The platform team has full control over what’s actually provisioned.GitOps: ArgoCD or FluxGitOps is table stakes in 2026. The choice between ArgoCD and Flux has settled into pragmatic camps:<ul><li>ArgoCD: Better UI, easier onboarding for developers new to GitOps</li><li>Flux: More composable, easier to manage as code at scale</li></ul>Either way, the workflow is the same: developers submit PRs, automated checks validate, merge triggers deployment. The platform team manages the GitOps controllers, not the application teams.Secrets: External Secrets Operator<a href="https://external-secrets.io/">External Secrets Operator</a> has become the standard way to sync secrets from AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, or Azure Key Vault into Kubernetes Secrets. Developers define what secrets they need; the platform handles where they come from.<div><pre><code>apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
 name: payment-service-credentials
spec:
 refreshInterval: 1h
 secretStoreRef:
 name: vault
 kind: ClusterSecretStore
 target:
 name: payment-service-credentials
 data:
 - secretKey: DATABASE_URL
 remoteRef:
 key: payment-service/staging
 property: database_url
</code></pre></div>Observability: OpenTelemetry + Grafana StackOpenTelemetry is now the universal instrumentation standard. Traces, metrics, and logs all flow through the OTel collector into whatever backend the platform team maintains (Grafana Cloud, Datadog, Honeycomb). The key win: instrumentation is standardized, so platform-wide changes (sampling rates, attribute enrichment, security scrubbing) happen at the collector layer without touching application code.<hr><h2 id="anti-patterns-to-avoid">Anti-Patterns to Avoid</h2>The accidental Terraform wrapper: Many platforms end up as thin wrappers around Terraform modules. This seems pragmatic but produces platforms where developers have to understand Terraform to debug failures. Use Crossplane or Pulumi Automation API instead — the Kubernetes/TypeScript APIs compose better with the rest of the platform.The ticket-driven platform: If using your platform requires submitting a ticket and waiting for a human, it’s not a platform — it’s a service desk with better tooling. Self-service is the minimum bar.Version proliferation: One team on Kubernetes 1.28, another on 1.31, six versions of your internal base image floating around. Establish a clear deprecation schedule and enforce it with hard cutoffs. Backwards compatibility is good; infinite backwards compatibility is a maintenance trap.Over-engineering scaffolding: I’ve seen platforms where generating a new service requires answering 47 questions. Developers should be able to create a new service in under 5 minutes with sane defaults. If they need to customize, they can edit the generated code.<hr><h2 id="developer-experience-metrics-that-matter">Developer Experience Metrics That Matter</h2>How do you know if your platform is actually working? Measure these:<img src="https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=800" alt="Dashboard showing developer productivity metrics"> Photo by Luke Chesser on UnsplashTime to first deployment (T2FD): How long from “I have a new service idea” to “it’s running in staging”? Target: under 30 minutes for a standard service.Deploy frequency: How often does each team deploy? Platforms that reduce friction enable more frequent, smaller deployments.Platform NPS: Quarterly surveys asking developers “would you recommend our platform to a colleague joining the company?” Track trends, not absolutes.Escape hatch usage: How often do teams bypass the golden path? High escape hatch usage signals the golden path isn’t covering enough ground.Platform ticket volume: Tickets to the platform team per developer per month. Should trend toward zero over time as self-service improves.Track these in a dashboard the entire engineering org can see. Accountability requires visibility.<hr><h2 id="organizational-patterns">Organizational Patterns</h2>Platform engineering fails when it’s treated as a purely technical problem. The organizational design matters as much as the technology choices.Platform as a product: The platform team has a product manager, runs user research, and treats application developers as customers. This isn’t a metaphor — it means product planning processes, roadmaps, and regular developer feedback sessions.Embedded feedback loops: Have platform engineers rotate through application teams for a week per quarter. Nothing surfaces friction like using your own product on a real project.The 80/20 rule: The platform should handle 80% of use cases well. The remaining 20% should be able to escape gracefully. Don’t try to solve everything — you’ll end up solving nothing well.SLOs for the platform: Platform teams often enforce SLOs on application teams but have none of their own. Define and publish SLOs for your CI/CD pipelines, self-service workflows, and infrastructure provisioning APIs. Hold yourself accountable.<hr><h2 id="the-platform-engineering-maturity-model">The Platform Engineering Maturity Model</h2>Level 0: Chaos — Every team does its own thing, no shared tooling, tribal knowledge everywhere.Level 1: Standardization — Common CI/CD pipelines, shared Terraform modules, basic documentation.Level 2: Self-Service — Developers can provision infrastructure, create services, and manage deployments without platform team involvement.Level 3: Product — Platform has a roadmap, metrics, and SLOs. Developer experience is actively measured and improved.Level 4: Ecosystem — Platform extends beyond infrastructure to include data, security, and ML tooling. Internal marketplace of verified integrations.Most teams are at Level 1–2. Level 3 is where the real productivity gains emerge. Level 4 is rare and requires significant investment.<hr><h2 id="what-id-build-today">What I’d Build Today</h2>If I were starting a platform engineering initiative from scratch in 2026:<ol><li>Start with Backstage — even a minimal deployment with the catalog and software templates gives immediate value and a foundation to build on.</li><li>Use Crossplane for infrastructure — the Kubernetes-native model composes well with GitOps and makes everything auditable.</li><li>Standardize on OpenTelemetry from day one — retrofitting observability is far more expensive than starting instrumented.</li><li>Build the golden path for your most common service type first — prove the model works before expanding scope.</li><li>Hire a developer experience engineer — someone whose entire job is reducing friction, running developer surveys, and improving the internal tooling. This role pays for itself quickly.</li></ol>The best platform engineering teams think of themselves as product teams that serve internal customers. The engineering challenges are interesting, but the customer service mindset is what makes them successful.<hr><h2 id="references">References</h2><ul><li><a href="https://teamtopologies.com/">Team Topologies</a> — the canonical book on platform team organizational patterns</li><li><a href="https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/">CNCF Platform Engineering Maturity Model</a> — industry-standard maturity framework</li><li><a href="https://docs.crossplane.io/">Crossplane Docs</a> — infrastructure composition for Kubernetes</li><li><a href="https://backstage.io/">Backstage.io</a> — open source developer portal framework</li><li><a href="https://external-secrets.io/">External Secrets Operator</a> — secrets management for Kubernetes</li></ul> <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

Platform engineering has become the dominant framing for infrastructure teams over the last two years. Virtually every mid-to-large engineering org now has a “platform team” or is building one. And yet, the pattern I see repeatedly: teams build sophisticated internal developer platforms (IDPs) that developers quietly ignore in favor of doing things manually or finding workarounds.
Why? Because platform teams often optimize for completeness and compliance rather than developer experience. They build platforms that can do everything and that developers have to fight to use. This post is about the patterns that produce platforms developers actually adopt.
The Core Problem: Cognitive Load Transfer
Platform engineering’s stated goal is to reduce cognitive load for application developers. But many IDPs simply transfer the cognitive load rather than eliminating it. Instead of thinking about Kubernetes YAML, developers now think about:
A bespoke CLI with inconsistent flags and incomplete documentation
A portal that requires understanding the platform team’s mental model
Multi-step workflows that could be automated but aren’t
Abstractions that leak at precisely the wrong moments
The platform should absorb complexity, not rename it.
What Good Platform Engineering Looks Like
The best IDPs I’ve seen share a few characteristics:
Golden paths, not golden cages. A golden path is the opinionated, well-maintained path that works for 80% of use cases and makes the right thing easy. A golden cage is a platform that forces everyone onto a single path, breaking when use cases diverge. Build the path, make it attractive, but provide escape hatches.
Paved roads, not toll roads. Developers shouldn’t have to justify using the platform’s tools or ask for access. The default experience should be self-service.
Thin abstractions. Every abstraction layer you add is a potential leak point. Prefer thin abstractions that compose well over thick ones that try to hide everything.
The Platform Engineering Stack in 2026
Photo by NASA on Unsplash
The tooling has consolidated significantly. The emerging reference stack:
Control Plane: Backstage + Crossplane
Backstage has won the developer portal battle. It’s not perfect, but its plugin ecosystem and wide adoption mean you’re not building alone. In 2026, a Backstage instance with the right plugins can serve as:
Service catalog
Software templates (scaffolding)
Infrastructure self-service
Documentation hub
Incident management portal
Crossplane has become the standard for infrastructure composition. Define your infrastructure as Kubernetes CRDs, compose complex environments from simple building blocks, and let developers provision resources through the Kubernetes API they already know.
# A developer creates this Composite Resource — no Terraform knowledge needed
apiVersion: platform.company.com/v1alpha1
kind: AppEnvironment
metadata:
  name: payment-service-staging
spec:
  parameters:
    environment: staging
    region: us-east-1
    database:
      engine: postgresql
      size: medium
    cache:
      enabled: true
      size: small
    serviceAccount:
      externalSecrets: true
The platform team defines the XRD (Composite Resource Definition) and composition. The developer only sees the AppEnvironment abstraction. The platform team has full control over what’s actually provisioned.
GitOps: ArgoCD or Flux
GitOps is table stakes in 2026. The choice between ArgoCD and Flux has settled into pragmatic camps:
ArgoCD: Better UI, easier onboarding for developers new to GitOps
Flux: More composable, easier to manage as code at scale
Either way, the workflow is the same: developers submit PRs, automated checks validate, merge triggers deployment. The platform team manages the GitOps controllers, not the application teams.
Secrets: External Secrets Operator
External Secrets Operator has become the standard way to sync secrets from AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, or Azure Key Vault into Kubernetes Secrets. Developers define what secrets they need; the platform handles where they come from.
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: payment-service-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault
    kind: ClusterSecretStore
  target:
    name: payment-service-credentials
  data:
    - secretKey: DATABASE_URL
      remoteRef:
        key: payment-service/staging
        property: database_url
Observability: OpenTelemetry + Grafana Stack
OpenTelemetry is now the universal instrumentation standard. Traces, metrics, and logs all flow through the OTel collector into whatever backend the platform team maintains (Grafana Cloud, Datadog, Honeycomb). The key win: instrumentation is standardized, so platform-wide changes (sampling rates, attribute enrichment, security scrubbing) happen at the collector layer without touching application code.
Anti-Patterns to Avoid
The accidental Terraform wrapper: Many platforms end up as thin wrappers around Terraform modules. This seems pragmatic but produces platforms where developers have to understand Terraform to debug failures. Use Crossplane or Pulumi Automation API instead — the Kubernetes/TypeScript APIs compose better with the rest of the platform.
The ticket-driven platform: If using your platform requires submitting a ticket and waiting for a human, it’s not a platform — it’s a service desk with better tooling. Self-service is the minimum bar.
Version proliferation: One team on Kubernetes 1.28, another on 1.31, six versions of your internal base image floating around. Establish a clear deprecation schedule and enforce it with hard cutoffs. Backwards compatibility is good; infinite backwards compatibility is a maintenance trap.
Over-engineering scaffolding: I’ve seen platforms where generating a new service requires answering 47 questions. Developers should be able to create a new service in under 5 minutes with sane defaults. If they need to customize, they can edit the generated code.
Developer Experience Metrics That Matter
How do you know if your platform is actually working? Measure these:
Photo by Luke Chesser on Unsplash
Time to first deployment (T2FD): How long from “I have a new service idea” to “it’s running in staging”? Target: under 30 minutes for a standard service.
Deploy frequency: How often does each team deploy? Platforms that reduce friction enable more frequent, smaller deployments.
Platform NPS: Quarterly surveys asking developers “would you recommend our platform to a colleague joining the company?” Track trends, not absolutes.
Escape hatch usage: How often do teams bypass the golden path? High escape hatch usage signals the golden path isn’t covering enough ground.
Platform ticket volume: Tickets to the platform team per developer per month. Should trend toward zero over time as self-service improves.
Track these in a dashboard the entire engineering org can see. Accountability requires visibility.
Organizational Patterns
Platform engineering fails when it’s treated as a purely technical problem. The organizational design matters as much as the technology choices.
Platform as a product: The platform team has a product manager, runs user research, and treats application developers as customers. This isn’t a metaphor — it means product planning processes, roadmaps, and regular developer feedback sessions.
Embedded feedback loops: Have platform engineers rotate through application teams for a week per quarter. Nothing surfaces friction like using your own product on a real project.
The 80/20 rule: The platform should handle 80% of use cases well. The remaining 20% should be able to escape gracefully. Don’t try to solve everything — you’ll end up solving nothing well.
SLOs for the platform: Platform teams often enforce SLOs on application teams but have none of their own. Define and publish SLOs for your CI/CD pipelines, self-service workflows, and infrastructure provisioning APIs. Hold yourself accountable.
The Platform Engineering Maturity Model
Level 0: Chaos — Every team does its own thing, no shared tooling, tribal knowledge everywhere.
Level 1: Standardization — Common CI/CD pipelines, shared Terraform modules, basic documentation.
Level 2: Self-Service — Developers can provision infrastructure, create services, and manage deployments without platform team involvement.
Level 3: Product — Platform has a roadmap, metrics, and SLOs. Developer experience is actively measured and improved.
Level 4: Ecosystem — Platform extends beyond infrastructure to include data, security, and ML tooling. Internal marketplace of verified integrations.
Most teams are at Level 1–2. Level 3 is where the real productivity gains emerge. Level 4 is rare and requires significant investment.
What I’d Build Today
If I were starting a platform engineering initiative from scratch in 2026:
Start with Backstage — even a minimal deployment with the catalog and software templates gives immediate value and a foundation to build on.
Use Crossplane for infrastructure — the Kubernetes-native model composes well with GitOps and makes everything auditable.
Standardize on OpenTelemetry from day one — retrofitting observability is far more expensive than starting instrumented.
Build the golden path for your most common service type first — prove the model works before expanding scope.
Hire a developer experience engineer — someone whose entire job is reducing friction, running developer surveys, and improving the internal tooling. This role pays for itself quickly.
The best platform engineering teams think of themselves as product teams that serve internal customers. The engineering challenges are interesting, but the customer service mindset is what makes them successful.
References
Team Topologies — the canonical book on platform team organizational patterns
CNCF Platform Engineering Maturity Model — industry-standard maturity framework
Crossplane Docs — infrastructure composition for Kubernetes
Backstage.io — open source developer portal framework
External Secrets Operator — secrets management for Kubernetes

Platform Engineering in 2026: Building Internal Developer Platforms That Developers Actually Use

댓글