DevOps told development teams to own their operations. The problem is that most development teams don’t want to be infrastructure experts—they want to build features. Platform engineering is the recognition that there’s a middle ground: giving teams operational ownership without requiring them to reinvent the wheel on every deployment.
The output of a platform engineering team is an Internal Developer Platform (IDP): the tools, automation, and golden paths that let application teams deploy, observe, and operate their software without deep infrastructure expertise.
What Platform Engineering Is (and Isn’t)
Platform engineering is not: A rebranded operations team that controls access to infrastructure. If your “platform” requires developers to open a ticket to get a new namespace, you’ve built a different kind of bureaucracy.
Platform engineering is: Building self-service infrastructure capabilities that developers can use without knowing the underlying details. A developer should be able to provision a new service, deploy it to staging, get an ingress and TLS cert, connect it to observability, and have monitoring configured—ideally without opening a ticket.
The KPI for a platform team isn’t uptime or cost efficiency (though those matter). It’s developer satisfaction and time-to-production for new services.
The Golden Path
The most important concept in platform engineering is the “golden path”—an opinionated, supported, maintained way to do a common task. Creating a new microservice. Provisioning a database. Deploying to a new environment. Configuring monitoring.
Golden paths are distinguished from mandates: they’re the paved road, not the only road. Teams can deviate for legitimate reasons. But the golden path should be so good that deviating feels like extra work. If your golden path for “deploy a new service” is better than the alternative of doing it from scratch, people will follow it.
A golden path typically includes:
- A scaffolding template (Backstage Software Template, cookiecutter, etc.)
- The CI/CD pipeline configuration
- A Helm chart template
- Monitoring/alerting defaults
- Documentation
When a developer runs the golden path template, they get a new git repo, a Helm chart, a CI pipeline, a ServiceMonitor for Prometheus, and default alerts—all pre-configured and working.
Backstage: The Portal
Backstage (from Spotify, now CNCF) is the dominant open-source solution for building an internal developer portal. It provides:
- Software Catalog: A central registry of all services, APIs, libraries, and infrastructure owned by your teams
- Software Templates: Golden path wizards that scaffold new services with all the right defaults
- TechDocs: Documentation living alongside code, rendered in the portal
- Plugins: Extensive plugin ecosystem for CI/CD, monitoring, cloud cost, security, etc.
The software catalog is the killer feature. When you have 50 microservices owned by 8 teams, knowing what exists, who owns it, where its docs are, what APIs it exposes, and where its dashboards are—without Backstage, this is tribal knowledge. With Backstage, it’s searchable.
# catalog-info.yaml in a service repo
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: my-payment-service
description: "Handles payment processing for the checkout flow"
annotations:
github.com/project-slug: org/payment-service
grafana/dashboard-selector: "title=payment-service"
jenkins.io/job-full-name: org/payment-service/main
spec:
type: service
lifecycle: production
owner: team-checkout
system: payment-platform
providesApis:
- payment-api-v2
consumesApis:
- fraud-detection-api
dependsOn:
- resource:default/payments-postgres
That file, committed to the service repo, registers the service in Backstage’s catalog. No ticket. No configuration in a central system. The catalog builds itself from the repos.
Self-Service Namespaces
One of the most common friction points: developers need a namespace. In most organizations, this involves a ticket, an ops team review, and some YAML being applied manually.
With Namespace-as-a-Service:
# Developer creates this in a self-service git repo
apiVersion: v1
kind: ConfigMap
metadata:
name: namespace-request-team-checkout
namespace: platform-requests
labels:
platform.company.com/namespace-request: "true"
data:
team: checkout
namespace: checkout-staging
environment: staging
quota-tier: standard
A Kubernetes operator watches for these ConfigMaps and provisions:
- The namespace
- ResourceQuota
- LimitRange defaults
- Default NetworkPolicies
- RBAC for the team’s service account
- Monitoring namespace registration
No ticket. Push a PR, get it approved, merge—namespace exists.
GitOps Tenancy
In a multi-team platform, each team should own their GitOps configuration:
clusters/production/
├── platform/ # Platform team owns this
│ ├── ingress-nginx/
│ ├── cert-manager/
│ ├── monitoring/
│ └── vault/
├── team-checkout/ # Checkout team owns this
│ ├── payment-service/
│ ├── cart-service/
│ └── namespace.yaml
└── team-catalog/ # Catalog team owns this
├── product-service/
└── search-service/
Each team’s path in the GitOps repo is their operational area. The platform team sets up Flux with appropriate RBAC so each team’s Flux ServiceAccount only has permissions in their namespace.
Measuring Platform Success
The DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, Mean Time to Recovery) are the industry standard for measuring platform effectiveness. But for an IDP specifically:
- Time to first deployment for a new service: How long from “I want a new service” to “it’s deployed in staging”?
- P90 time to production: What does the 90th percentile journey from commit to production look like?
- Number of tickets opened to do routine work: If developers still need to open tickets for common operations, the platform isn’t self-service yet.
- Developer satisfaction (NPS): Platform teams work for developers. Ask them if the platform is working.
The Paved Road vs. Dirt Path
The platform should make the right thing easy and the wrong thing harder (but not impossible). Examples:
- Right thing easy: Deploying with the standard Helm chart template gets you resource limits, health checks, monitoring, and PDBs by default.
- Wrong thing harder: If a team wants to deploy without resource limits, they have to explicitly override the defaults—which creates a conversation.
This isn’t about control. It’s about defaults that reflect organizational standards, which developers can override with conscious intent.
When Platform Engineering Goes Wrong
Platform engineering fails when:
- The platform team doesn’t talk to developers: Building what you think developers need vs. what they actually need.
- Everything requires a ticket: Self-service is the whole point.
- The golden path is worse than the alternatives: If it’s faster to do it by hand, nobody will use the platform.
- Too much standardization: Forcing every service into the same template even when the template doesn’t fit.
- The platform team becomes a bottleneck: Approving every change rather than building automated guardrails.
Good platform engineering feels invisible to developers. They use the tools and the right things happen. They don’t think about the platform—they think about their product. That’s success.
