DevOps promised that development teams would own their entire delivery pipeline. The reality: most teams are drowning in operational complexity. Every team manages its own CI/CD, its own infrastructure config, its own monitoring setup, and its own deployment scripts. The cognitive load on developers has exploded.
Platform engineering is the response. Instead of every team building their own operations layer, a dedicated platform team builds an Internal Developer Platform (IDP) that abstracts the complexity and provides developer self-service. Gartner predicts 80% of software engineering organisations will have platform teams by the end of 2026.
What Platform Engineering Is
Platform engineering is the practice of building and maintaining an internal platform that provides development teams with self-service capabilities for infrastructure, deployment, and operations.
The platform team builds golden paths — opinionated, pre-configured workflows that represent the best way to do common tasks (deploy a service, create a database, set up monitoring). Development teams follow the golden path for 80% of their work and have escape hatches for the other 20%.
The key insight: Platform engineering is not "DevOps renamed." It's a fundamentally different operating model:
| Aspect | Traditional DevOps | Platform Engineering |
|---|---|---|
| Philosophy | "You build it, you run it" (every team) | "We build the platform, you build the product" |
| Infrastructure | Each team manages their own | Platform team provides self-service |
| Cognitive load | High (every developer is also an ops person) | Low (developers focus on business logic) |
| Consistency | Variable across teams | Standardised via golden paths |
| Scaling | Doesn't scale (linear complexity per team) | Scales (platform serves all teams) |
The Internal Developer Platform
What It Provides
| Capability | Description | Example |
|---|---|---|
| Service catalog | Discover and create new services from templates | "Create a new Node.js microservice" |
| Environment management | Self-service creation of dev/staging environments | "Spin up a preview environment for this PR" |
| Infrastructure provisioning | Request and configure infrastructure | "I need a PostgreSQL database for my service" |
| CI/CD abstraction | Standardised deployment pipelines | "Deploy my service to staging, then production" |
| Observability | Built-in monitoring, logging, and alerting | "Show me my service's health dashboard" |
| Documentation | Centralised, discoverable technical documentation | "Find the API docs for the payments service" |
| Security | Automated security scanning and compliance | "Show my service's security posture" |
The Five Layers
┌─────────────────────────────────────┐
│ 5. Interface Layer │ ← Developer portal (Backstage, custom)
├─────────────────────────────────────┤
│ 4. Delivery Layer │ ← CI/CD, GitOps (ArgoCD, GitHub Actions)
├─────────────────────────────────────┤
│ 3. Integration Layer │ ← Service mesh, API gateway, messaging
├─────────────────────────────────────┤
│ 2. Resource Layer │ ← Databases, storage, caching, queues
├─────────────────────────────────────┤
│ 1. Infrastructure Layer │ ← Kubernetes, cloud resources, networking
└─────────────────────────────────────┘
Technology Choices
Developer Portal: Backstage
Spotify's Backstage has become the de facto standard for developer portals. It provides:
- Service catalog (all services, their owners, documentation, APIs)
- Software templates (scaffolding for new services)
- TechDocs (documentation-as-code, rendered in the portal)
- Plugin ecosystem (integrations with CI/CD, monitoring, cloud providers)
Infrastructure Orchestration
| Tool | Approach | Best For |
|---|---|---|
| Crossplane | Kubernetes-native, declarative resource management | Teams already on Kubernetes |
| Terraform | State-managed, plan/apply workflow | Multi-cloud, established teams |
| Pulumi | Programming languages for IaC | Teams that prefer code over config |
| Humanitec | Platform Orchestrator, score-based | Fastest time to value, less customisation |
Delivery
| Tool | Approach | Best For |
|---|---|---|
| ArgoCD | GitOps for Kubernetes | K8s-native delivery |
| Flux | GitOps for Kubernetes | Lightweight, CNCF |
| GitHub Actions | CI/CD pipelines | GitHub-centric workflows |
| Azure DevOps | End-to-end CI/CD | Azure-centric enterprises |
Building the Platform Team
Team Structure
Size: Start with 2-3 engineers. Scale to 1 platform engineer per 10-15 application developers.
Skills needed:
- Infrastructure and cloud expertise (Kubernetes, cloud services, networking)
- Software engineering (the platform is a product — treat it like one)
- Developer experience mindset (empathy for your users — the developers)
The Platform-as-a-Product Mindset
The platform team's customers are the development teams. Treat the platform like a product:
- Product owner: Someone who talks to development teams, understands their pain points, and prioritises the platform roadmap
- User research: Regular surveys, interviews, and observation of how developers use (or don't use) the platform
- Roadmap: Published, transparent, and informed by developer feedback
- Documentation: Comprehensive, up-to-date, discoverable
- SLAs: The platform has reliability targets, just like any product
Measuring Platform Success
| Metric | What It Measures | Target |
|---|---|---|
| Developer satisfaction (NPS) | Do developers find the platform useful? | Above 50 |
| Time to first deployment | How fast can a new developer deploy to production? | Under 1 day |
| Self-service rate | % of infrastructure requests handled without platform team involvement | Above 80% |
| Deployment frequency | Are teams deploying faster? | Increasing |
| Lead time for changes | Is the path to production faster? | Decreasing |
| Platform adoption | % of teams using the platform | Above 90% within 12 months |
| Cognitive load | Developer-reported effort for operational tasks | Decreasing |
Anti-Patterns
Building Everything Before Validating
Don't build a comprehensive platform and hope developers adopt it. Start with the highest-pain-point problem (usually CI/CD or environment management), prove value, and expand.
Mandating Without Value
If you mandate platform usage without the platform being genuinely better than what teams built themselves, you'll face resistance and shadow IT.
Ignoring the Escape Hatch
Golden paths work for 80% of use cases. The other 20% need flexibility. If the platform is too rigid, teams will route around it entirely.
Platform Team as Gatekeepers
The platform team enables, not gates. If developers need to file a ticket and wait for the platform team to provision infrastructure, you've recreated the old ops model.
Platform engineering is the most impactful investment in developer productivity that a technology organisation can make. If you're building a platform team or evaluating platform engineering, let's talk.