What is Platform Engineering? Internal Developer Platforms Explained
Platform engineering emerged as a direct response to a scaling problem that DevOps creates. When you tell every team to own their own infrastructure, you get fast teams -- and eventually a mess of inconsistent tooling, repeated work, and a skills gap between teams who are strong on infrastructure and those who are not. Platform engineering is the answer to that mess.
The Core Idea: Paved Roads
The central metaphor in platform engineering is the "golden path" or "paved road." Rather than forcing application developers to make hundreds of infrastructure decisions -- which cloud services to use, how to set up monitoring, how to structure deployment pipelines -- the platform team makes those decisions once, encodes them into opinionated tooling, and offers them as a self-service product.
A developer using the platform might run a single command to provision a new service:
platform new service --name payments-api --template python-fastapi
# Output:
# Creating GitHub repository: payments-api
# Provisioning staging environment on EKS
# Configuring Datadog monitoring
# Setting up CI/CD pipeline in GitHub Actions
# Service ready: https://payments-api.internal.example.com
That one command might be triggering Terraform modules, Kubernetes manifests, Backstage catalogue entries, and GitHub Actions workflows behind the scenes. The developer does not need to know any of that. They get a working service with sensible defaults.
What Goes Into an Internal Developer Platform
An IDP is not a single product you buy -- it is a product your platform team builds, usually by composing existing tools. Mature IDPs typically cover:
Self-service provisioning -- Developers can create new services, databases, queues, and environments without filing tickets or waiting for an ops engineer. Crossplane, Terraform modules, and Helm charts are common building blocks.
Deployment and delivery -- A standardised path from code commit to production. GitOps tools like ArgoCD or Flux manage the synchronisation between Git state and cluster state. The platform team owns the patterns; developers own the application code.
Secrets and configuration management -- A consistent, secure way to inject secrets and environment-specific configuration. HashiCorp Vault, AWS Secrets Manager, and External Secrets Operator are common choices.
Observability by default -- Every service provisioned through the platform gets logging, metrics, and tracing automatically. Developers do not opt in to monitoring; they opt out of it if they have a reason.
Developer portal -- A service catalogue (often Backstage) where teams can discover services, see ownership, access runbooks, and trigger self-service workflows.
Platform Engineering vs DevOps
The relationship between platform engineering and DevOps is often misunderstood. Platform engineering does not replace DevOps -- it enables it at scale.
Early-stage DevOps tells every team to own their infrastructure. That works when you have five teams. With fifty teams, it produces an enormous amount of duplicated effort and inconsistency. Platform engineering introduces a dedicated team whose product is the infrastructure capabilities other teams consume.
The key distinction from old-style ops: platform teams build products for internal customers. They treat their tooling with the same product discipline as application teams -- roadmaps, user research, SLOs for the platform itself. They do not own or approve every deployment. They build the tooling that makes good deployments easy and bad ones hard.
The Team Topology Angle
The Team Topologies framework (by Matthew Skelton and Manuel Pais) formalised the platform team as one of four fundamental team types. In this model, the platform team provides a compelling internal product that reduces cognitive load for stream-aligned teams (the teams building user-facing features).
The anti-pattern the model warns against is a platform team that becomes a gate -- an ops team rebranded, where every change still requires approval. A real platform team measures itself by adoption and developer satisfaction, not by tickets processed.
Why Platform Engineering Is Growing
The economics are compelling. Infrastructure as code, CI/CD, and Kubernetes have made it possible for a small team to build genuinely powerful abstractions. The Gartner prediction that 80% of large software engineering organisations will have platform engineering teams by 2026 reflects a real trend -- not hype.
For a deeper look at the tooling that platform teams build on, see the devops tools guide.