I spent a good chunk of 2023 arguing with a VP of Engineering about whether our company "needed DevOps or Platform Engineering." It was the wrong question. By the time we shipped our internal developer platform in early 2024, I understood why: DevOps is a culture, and Platform Engineering is a discipline. Conflating the two is like confusing Agile with Scrum — one is a philosophy, the other is a set of tools and practices you use to live it.
In 2026, this distinction matters more than ever. Engineering organizations are larger, cloud bills are more painful, and developer cognitive load has crossed a threshold where good engineers are leaving not because the work is hard, but because the friction is intolerable. Platform Engineering is the answer to that friction. This post is everything I know about making it work.
1. What Is Platform Engineering — and Why It's Not Just "DevOps Renamed"
Platform Engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations. The platform team's customer is the internal developer. Their product is the Internal Developer Platform (IDP).
DevOps, by contrast, is a cultural and organizational movement aimed at breaking down silos between development and operations teams. It doesn't prescribe a specific toolchain or team structure. DevOps told us what to value — collaboration, automation, fast feedback, shared ownership. Platform Engineering tells us how to operationalize those values at scale.
Here's the practical difference: a company practicing DevOps might have every team responsible for their own CI/CD pipelines, their own Kubernetes configurations, their own security scanning setup. That works when you have five engineers. It breaks down catastrophically when you have five hundred. Every team reinvents the wheel. Security standards drift. Onboarding a new developer takes three weeks because they have to learn fifteen different internal systems.
Platform Engineering centralizes that undifferentiated heavy lifting. A dedicated Platform team builds and maintains the golden paths — the opinionated, supported, well-documented routes for doing common development tasks. Other teams can deviate if they have good reason, but they don't have to. The default path just works.
The "You Build It, You Run It" Trap
Amazon's "you build it, you run it" principle was genuinely influential. It gave teams ownership and accountability. But taken too far, it means every product team is also an infrastructure team, a security team, a compliance team, and a tooling team. That's not sustainable. In my experience, teams that "run it" end up spending 40% of their sprint capacity on operational overhead that has nothing to do with their actual product.
Platform Engineering gives you the ownership benefits of DevOps without forcing every developer to become a platform engineer. The platform team handles the boring, critical infrastructure. Product teams focus on product.
2. What Goes Into an Internal Developer Platform
An IDP is not a single product you buy. It's a curated collection of capabilities — some off-the-shelf, some custom — wired together to serve your developers. The core capabilities fall into five categories:
Application Configuration Management
How are environment variables, feature flags, and secrets managed? This typically involves a secrets manager (HashiCorp Vault is the most common choice), a feature flag system (LaunchDarkly, Unleash), and a configuration API that services can query at startup or runtime.
Infrastructure Orchestration
How does a developer provision a database, a message queue, a cache? In a mature IDP, they shouldn't need to file a ticket. Crossplane is increasingly the tool of choice here — it extends Kubernetes to let you define cloud resources as Kubernetes Custom Resources. A developer creates a PostgreSQL CRD, and Crossplane provisions the actual RDS instance on AWS. No Terraform knowledge required on the product team side.
Environment Management
Ephemeral environments — preview environments spun up per pull request, torn down when the PR closes — are a hallmark of a mature IDP. Tools like Argo CD for GitOps and Helm for templating make this achievable. Some platforms use Terraform workspaces or Pulumi stacks for environment isolation.
Deployment (CI/CD)
A golden path for deployment typically includes: a standard CI pipeline template (GitHub Actions workflow, Tekton pipeline, or Jenkins shared library), a GitOps workflow with Argo CD or Flux for Kubernetes workloads, and progressive delivery patterns (canary, blue/green) handled by Flagger or Argo Rollouts.
Developer Portal
All of the above is useless if developers can't find or understand it. The developer portal is the front door to the IDP. Spotify Backstage has become the de facto standard here, and I'll cover it in depth shortly.
3. The Golden Path: Opinionated by Design
The "golden path" (sometimes called "paved road") is the most important concept in Platform Engineering. It is a pre-built, well-tested, well-documented path for accomplishing a common development task. Golden paths cover things like:
- Creating a new microservice (scaffolding with all security defaults baked in)
- Deploying to production (CI/CD pipeline + progressive delivery)
- Adding a database (self-service via the developer portal)
- Managing secrets (Vault integration, no hardcoded credentials)
- Setting up observability (Prometheus + Grafana + Loki, pre-configured)
The key word is opinionated. A golden path makes choices on behalf of the developer. You're not giving them a menu of twelve ways to deploy a service. You're giving them one way that works, with sensible defaults, and letting them override specific parts if they have a genuine reason.
Callout: The 80/20 Rule of Golden Paths
A golden path should cover 80% of use cases without customization. The remaining 20% can deviate — but deviation should be a conscious choice, documented, and ideally flagged in your developer portal so the platform team knows where their coverage gaps are. Never make deviation impossible; make the golden path so good that most teams don't want to deviate.
Implementing a Golden Path in Practice
A concrete golden path for a new microservice at a company I worked with looked like this:
- Developer clicks "Create Service" in Backstage, fills in a form: service name, team owner, language (Go/Node/Python), data stores needed.
- Backstage runs a Cookiecutter/Scaffolder template that creates a GitHub repo with: Dockerfile, GitHub Actions CI workflow, Helm chart, basic health check endpoint, Vault integration code, and an initial OWNERS file.
- The CI pipeline automatically runs on every PR: lint, unit tests, container build, Trivy security scan, SAST scan.
- Merging to main triggers Argo CD, which deploys to the staging cluster. A Slack notification goes to the team's channel.
- Promoting to production is a one-click operation in the developer portal (or a git tag, depending on your preference).
From "I need a new service" to "I have a running service in staging" took about 12 minutes. Before we built this, it took 2–3 days of tickets, waiting, and manual configuration.
4. Developer Self-Service vs. Central Gatekeepers: The Core Trade-off
Every platform team eventually confronts the same tension: how much autonomy do you give developers, and how much control do you retain centrally?
The gatekeeper model — where every infrastructure change goes through a platform team review — scales poorly. It creates bottlenecks, breeds resentment, and defeats the purpose of having an IDP. I've seen platform teams become the thing they were supposed to replace: a slow operations team with a different name.
The full self-service model — where developers can provision anything without approval — creates security and cost nightmares. I've seen teams spin up $50,000/month of unused infrastructure because nobody was watching.
The right answer is guardrails, not gatekeepers. The platform team encodes policies into the platform itself:
- OPA/Gatekeeper policies in Kubernetes that reject manifests violating security standards (no root containers, mandatory resource limits, required labels).
- Terraform Sentinel or Checkov policies in CI that block infrastructure-as-code with insecure configurations.
- Budget alerts and namespace-level resource quotas that prevent any one team from overprovisioning.
- Vault policies that automatically scope secret access to the requesting service's identity.
With guardrails in place, developers can move freely within a safe perimeter. The platform team doesn't review every change — they define and maintain the perimeter.
5. Spotify Backstage: Deep Dive
Backstage is an open-source developer portal framework originally built at Spotify and donated to the CNCF in 2020. By 2026, it's the most widely adopted developer portal solution, with hundreds of enterprise deployments and a plugin ecosystem of over 300 community plugins.
The three core building blocks of Backstage:
The Software Catalog
The catalog is Backstage's backbone. Every service, library, API, website, and pipeline is registered as a "Component" in the catalog, described by a YAML file (catalog-info.yaml) checked into its own repository. The catalog aggregates metadata from all your repos and gives you a single searchable inventory of every software artifact your organization owns, who owns it, its health status, and its dependencies.
This sounds mundane until you've worked at a company where nobody knows which team owns the payment service or what version is running in production. The catalog solves the discovery problem — and at scale, that problem is surprisingly painful.
The Scaffolder (Software Templates)
The Scaffolder is how you implement golden paths in Backstage. You write a template (in YAML + Nunjucks) that defines a form presented to the developer and a series of actions to execute when the form is submitted. Actions include creating repositories, rendering files from templates, creating issues, registering the new component in the catalog, and running arbitrary webhooks.
A well-written Scaffolder template is invisible to the developer. They fill in a form. A working codebase appears. They don't need to know what happened under the hood.
TechDocs
TechDocs brings documentation next to the code. Teams write their docs in Markdown, check them into the same repo as the code, and TechDocs renders them in Backstage with a unified look. The advantage over Confluence or Notion: documentation lives in the repo, it's versioned alongside the code, and it shows up in the same place developers look when they're already browsing a service in the catalog.
The Plugin Architecture
Everything in Backstage is a plugin. Kubernetes workload visibility, CI/CD pipeline status, cost data from your cloud provider, on-call schedules, security scan results, API documentation — all pluggable. The community has built plugins for Argo CD, PagerDuty, Datadog, Vault, GitHub Actions, and dozens more. When you can't find a plugin, you write one in React + TypeScript. The plugin API is well-documented and the scaffolding tooling generates a working plugin skeleton in minutes.
Callout: Backstage Adoption Reality Check
Backstage is powerful but not free. A production Backstage deployment requires ongoing maintenance: plugin updates, catalog ingestion performance tuning, auth integration, and the inevitable organizational politics of getting every team to add a catalog-info.yaml to their repos. Budget at least one dedicated engineer to own Backstage. Companies that treat it as a "set it and forget it" deploy end up with a stale, unmaintained portal that developers stop using within six months.
6. Kubernetes-Based IDP Architecture
Kubernetes has become the infrastructure substrate for most modern IDPs, and for good reason: its declarative API, controller model, and extensibility via Custom Resource Definitions make it an excellent foundation for building platform abstractions.
A typical IDP architecture built on Kubernetes looks like this:
Control Plane Cluster
A dedicated cluster (or set of clusters) for platform tooling: Argo CD, Crossplane, Vault, the Backstage deployment, and your CI/CD runners. This is separate from workload clusters. Mixing platform tooling with application workloads creates blast-radius and upgrade problems you don't want.
Workload Clusters
Typically organized by environment (dev, staging, production) and sometimes by team or domain for large organizations. Argo CD syncs GitOps repositories to these clusters. Crossplane resources provisioned in the control plane cluster often create resources in cloud accounts associated with workload clusters.
Crossplane for Infrastructure Abstraction
Crossplane deserves special attention. It lets your platform team define "Composite Resources" — high-level abstractions that compose multiple cloud resources. For example, your platform team defines a "DatabaseInstance" composite resource that provisions an RDS instance, a secret in Vault with the connection string, and a VPC security group rule — all from a single, developer-friendly CRD. The developer doesn't write Terraform or CloudFormation. They create a DatabaseInstance resource and Crossplane handles everything else.
Argo CD for GitOps
Argo CD is the deployment engine. All application state lives in Git. Argo CD continuously reconciles the cluster state with the desired state in Git. Developers promote to production by merging a PR that updates an image tag or Helm values file. The audit trail is inherent: every deployment is a git commit with author, timestamp, and diff.
Vault for Secrets
HashiCorp Vault handles secrets across the entire platform. The Vault Secrets Operator (VSO) or External Secrets Operator (ESO) syncs secrets from Vault into Kubernetes Secrets. Applications authenticate to Vault using Kubernetes service account tokens — no static credentials. Vault also handles dynamic credentials: rather than storing a long-lived database password, Vault generates a short-lived credential on demand and revokes it automatically.
7. Platform as a Product
The most important mindset shift in Platform Engineering is treating the platform as a product. This sounds obvious, but most platform teams fall into the trap of building what they think developers need rather than what developers actually need.
A product mindset means:
- Developer experience interviews: Regularly sit with developers and watch them use the platform. Where do they get stuck? What do they Google? What workarounds have they built?
- Adoption metrics: Track how many teams use each golden path. Low adoption is feedback, not a developer attitude problem.
- A roadmap: The platform team should have a public roadmap that developers can see and influence. This builds trust and reduces the "why isn't the platform team working on what I need" frustration.
- SLAs and on-call: The platform is infrastructure that other teams depend on. It needs reliability commitments and someone responsible for keeping it healthy.
- Deprecation policy: Old capabilities need to be sunset, but with communication and migration support. Dropping a platform capability without warning is how you lose developer trust permanently.
Internal NPS
I use an internal NPS (Net Promoter Score) survey sent to developers quarterly: "How likely are you to recommend the internal developer platform to a colleague?" Paired with qualitative follow-up, this gives you a directional signal on platform health that you can trend over time. When our IDP NPS dropped from +42 to +21 in Q3 2024, it told us something was wrong before any executive noticed. It turned out our CI pipeline times had regressed by 40% after a runner infrastructure change. We fixed it in two weeks. That kind of fast feedback loop is only possible if you're measuring.
8. DORA Metrics and Platform Engineering
The four DORA (DevOps Research and Assessment) metrics are the most widely used framework for measuring software delivery performance:
- Deployment Frequency: How often does your organization deploy to production?
- Lead Time for Changes: How long does it take from code commit to running in production?
- Change Failure Rate: What percentage of deployments cause a production incident?
- Mean Time to Recovery (MTTR): How long does it take to restore service after an incident?
Platform Engineering has a direct causal relationship with all four metrics:
Deployment Frequency improves when deploying is easy and safe. A golden path that makes production deployment a one-click operation removes the fear that keeps teams batching changes. Before our IDP, teams deployed weekly because the process was painful. After, the same teams deployed multiple times per day.
Lead Time for Changes falls when developers spend less time on environment setup, secrets management, and infrastructure configuration. The scaffolding golden path alone reduced our average lead time for new service creation from 3 days to 2 hours.
Change Failure Rate drops when the golden path includes quality gates: mandatory tests, security scans, and progressive delivery (canary deployments catch failures on a small subset of traffic before they hit everyone).
MTTR improves when observability is standardized. If every service emits the same set of metrics and logs in the same format, oncall engineers can diagnose incidents faster because they aren't figuring out how to query service-specific monitoring setups.
Callout: Don't Optimize DORA Metrics in Isolation
I've seen teams game their DORA metrics by shipping tiny, low-risk changes constantly to inflate Deployment Frequency while quietly accumulating technical debt. DORA metrics are indicators, not goals. Use them to identify constraints in your delivery pipeline, not to create perverse incentives. Always pair them with business outcomes: are customers getting value faster?
9. Team Topologies Framework
Matthew Skelton and Manuel Pais's Team Topologies (2019) gave Platform Engineering a vocabulary and an organizational model that has aged remarkably well. The framework defines four team types:
Stream-Aligned Teams
Teams aligned to a flow of work (a product area, a customer segment, a business capability). These are your product teams. They should be able to deliver value end-to-end with minimal dependencies on other teams.
Platform Teams
Teams that build and maintain the internal platform. Their purpose is to reduce cognitive load on stream-aligned teams by providing self-service capabilities. The platform team's success is measured by stream-aligned team productivity, not by the platform team's output.
Enabling Teams
Temporary teams that help stream-aligned teams adopt new capabilities. An enabling team might spend a quarter helping all product teams migrate to the new observability stack, then dissolve. They transfer knowledge; they don't own the tooling permanently.
Complicated Subsystem Teams
Teams responsible for systems requiring deep specialist knowledge (real-time video encoding, ML training infrastructure, specialized databases). These teams exist to let stream-aligned teams consume complex capabilities without needing to understand the internals.
In Platform Engineering practice, the Team Topologies framework suggests that the Platform Team should use an "X-as-a-Service" interaction model with stream-aligned teams: the platform is a product that teams consume with minimal coordination overhead. The more a platform team needs to be "in the loop" for stream-aligned team decisions, the more the cognitive load reduction is failing.
10. The 12-Month IDP Roadmap: 0 to Platform
This is the sequence I'd recommend for an engineering organization starting from scratch with no formal Platform Engineering practice. Assume a mid-size company: 50–200 engineers, microservices architecture, AWS or GCP, Kubernetes already in use (or in evaluation).
Months 1–2: Discovery and Team Formation
Don't build anything yet. Spend two months interviewing developers. Map your current developer journey from "I have an idea" to "it's in production." Identify the top five pain points. Form a platform team of 2–3 engineers plus a product manager. The PM role is non-negotiable — without someone managing the roadmap and developer relationships, platform teams drift toward building what's technically interesting rather than what's needed.
Months 3–4: Foundation
Stand up the control plane cluster. Deploy Argo CD. Establish a GitOps repository structure. Migrate at least one team to GitOps deployment. Deploy Vault. Integrate Vault with Kubernetes. This alone — GitOps + centralized secrets — will eliminate a significant class of deployment problems and security incidents.
Months 5–6: First Golden Path
Build the golden path for your highest-frequency development task. In most organizations, that's "create a new service" or "deploy a new version of an existing service." Deploy Backstage with the Software Catalog populated with your existing services. Build the first Scaffolder template. Run it with at least three product teams and collect feedback aggressively.
Months 7–8: Infrastructure Self-Service
Integrate Crossplane. Build the first composite resource (probably a database). Let product teams provision databases without tickets. Add OPA/Gatekeeper policies to enforce security standards in Kubernetes. This is where you start shifting from "platform team is a bottleneck" to "platform team is a multiplier."
Months 9–10: Observability Golden Path
Standardize on a metrics/logging/tracing stack (Prometheus/Grafana/Loki/Tempo or Datadog if budget allows). Build golden path tooling that auto-configures observability for any service created via the Scaffolder template. Ship a Backstage plugin that shows each service's key metrics and recent incidents in the catalog.
Months 11–12: Progressive Delivery and Measurement
Implement Argo Rollouts or Flagger for canary deployments. Make canary the default deployment strategy for production. Instrument your DORA metrics. Run your first internal developer NPS survey. Use the data to plan your Year 2 roadmap.
11. Cost vs. ROI: Does Platform Engineering Pay?
The business case for Platform Engineering is compelling, but you need to build it carefully because the costs are concentrated (you're hiring a dedicated team) and the benefits are diffuse (every developer gets a little faster).
Let's do rough math. Assume:
- 100 product engineers at an average fully-loaded cost of $200K/year
- Current overhead: 25% of engineering time on infrastructure, tooling, and environment issues (a conservative industry estimate — Puppet's State of DevOps reports consistently show 25–40% overhead in organizations without mature platforms)
- Target overhead after IDP: 10%
- Platform team cost: 5 engineers at $200K + $100K tooling/infrastructure = $1.1M/year
15% time savings across 100 engineers at $200K = $3M in recovered engineering capacity annually. Even if your IDP only captures half that productivity improvement, you're at $1.5M recovered — a clear positive ROI against $1.1M platform team cost. And that ignores the harder-to-quantify benefits: reduced security incidents, faster onboarding, improved developer retention.
In practice, I've seen organizations achieve 2–4 hour reductions in deployment lead time within the first six months of an IDP. For 50 engineers deploying 3 times per week, that's meaningful throughput recovery.
12. Common Mistakes (That I Made, So You Don't Have To)
Over-Abstracting Too Early
The temptation when building a platform is to abstract everything. Why should developers care whether they're on AWS or GCP? Build a cloud-agnostic layer! In practice, perfect cloud abstraction is an enormous engineering investment that usually doesn't survive contact with reality. Start with your actual cloud and add abstraction only where it genuinely reduces developer cognitive load. I wasted four months on a "universal infrastructure API" that nobody used because the AWS-specific Crossplane resources were already simple enough.
Forced Adoption
Mandating that all teams use the platform before it's good enough is how you kill a platform program. Developers who are forced to use a bad tool will complain loudly, management will hear "platform engineering is failing," and the program gets cancelled. Let early adopters pull the platform forward. Find the two or three teams who are excited about the golden path, work closely with them, make them successful, and let their success sell the platform to skeptics.
Neglecting Documentation
The best platform capability is useless if developers don't know it exists or how to use it. I've seen teams build elaborate self-service tooling that nobody found because there was no entry point in the developer portal and no announcement in Slack. Treat documentation and communication as first-class deliverables. Every new capability needs a TechDocs entry, a Backstage catalog page, and a Slack announcement in the engineering all-hands channel.
Building What Platform Engineers Find Interesting
Platform engineers, by selection, are infrastructure nerds. Left unchecked, platform teams will optimize their Kubernetes control plane, experiment with service mesh, and rebuild their CI system from scratch — while product teams are still waiting for basic self-service database provisioning. The PM on the platform team is the counterweight. They prioritize the roadmap based on developer feedback, not platform team enthusiasm.
13. 2026 Trends: AI-Assisted Platforms and the Internal AI Gateway
Two trends are reshaping Platform Engineering in 2026: AI-assisted development and the emergence of the Internal AI Gateway as a first-class platform capability.
AI in the Golden Path
The most tangible change in 2026 is AI-assisted code generation becoming a first-class part of the development workflow. Platform teams now need to provision and manage AI development tools (GitHub Copilot, Cursor, JetBrains AI) with the same rigor as any other developer tool: license management, acceptable use policies, data privacy controls, and standardized configuration.
More interesting is AI being woven into the golden path itself. I've seen platform teams build Backstage plugins that use Claude or GPT-4o to generate Helm chart values, suggest resource limits based on similar services, and flag potential security issues in IaC before CI runs.
The Internal AI Gateway
As organizations build AI-powered features into their products, they face a new infrastructure challenge: how do you give product teams access to LLM APIs (OpenAI, Anthropic, Gemini) in a way that's cost-controlled, auditable, rate-limited, and compliant with data residency requirements?
The answer that's emerging is the Internal AI Gateway — a platform capability that sits in front of LLM provider APIs and provides:
- Unified authentication (teams don't handle individual API keys)
- Usage tracking and showback per team
- Prompt logging for compliance and debugging
- Fallback routing (if OpenAI is down, route to Anthropic)
- PII detection and redaction before prompts leave the corporate network
Tools like Kong AI Gateway, Portkey, and LiteLLM are being adopted as the backend for Internal AI Gateways. By 2026, "AI Gateway" is appearing on Platform team roadmaps at the same rate "secrets management" did in 2020.
14. Comparison: Traditional DevOps vs. Platform Engineering
| Dimension | Traditional DevOps | Platform Engineering |
|---|---|---|
| Core focus | Culture, collaboration, breaking silos | Self-service developer tooling at scale |
| Team structure | Embedded DevOps engineers in product teams | Dedicated platform team serving all teams |
| Tooling ownership | Each team owns its own pipeline/infra | Centralized golden paths with self-service |
| Scale sweet spot | Small teams (5–50 engineers) | Mid-to-large teams (50+ engineers) |
| Developer experience | Teams responsible for their own DX | Platform team owns DX as a product |
| Infrastructure changes | Often requires cross-team coordination | Self-service via catalog + Crossplane |
| Standardization | Loose, often tribal knowledge | Enforced via platform policies and templates |
| Onboarding time | High (learn each team's setup) | Low (one golden path to learn) |
| Security/compliance | Audit each team separately | Platform enforces policies centrally |
| Cost visibility | Hard to attribute per team | Built-in via namespace/label conventions |
15. Key Takeaways
- Platform Engineering operationalizes DevOps culture. DevOps tells you what to value; Platform Engineering builds the systems that make those values practical at scale. They're complementary, not competing.
- The golden path is your most important deliverable. An opinionated, well-supported path for the most common development tasks eliminates the majority of developer friction. Build it for the 80% case, allow deviation for the 20%.
- Treat the platform as a product. That means a roadmap, developer interviews, adoption metrics, an internal NPS, SLAs, and a product manager. Without this discipline, platform teams drift toward technically interesting work that doesn't move developer productivity.
- Backstage + Crossplane + Argo CD + Vault is the reference IDP stack in 2026. Each can be substituted, but this combination has the deepest ecosystem support and the widest community adoption.
- Guardrails beat gatekeepers. Encode your policies into OPA/Gatekeeper, Terraform Sentinel, and Vault policies. Let developers move freely within a safe perimeter rather than requiring platform team approval for every change.
- DORA metrics give you feedback loops. Track all four. Deployment Frequency and Lead Time tell you if the golden path is working. Change Failure Rate tells you if quality gates are working. MTTR tells you if observability is working.
- The Internal AI Gateway is the new "secrets management." If your organization is building AI-powered features, the platform team will need to provide managed, auditable access to LLM APIs. Plan for this in your Year 2 roadmap if not sooner.
Building an internal developer platform? I documented the automation patterns that make it scale — See what I built
댓글
댓글 쓰기