Platform Engineering
A discipline focused on building and maintaining Internal Developer Platforms (IDPs) that enable self-service capabilities for software engineering organizations.
Core Concept
Platform Engineering is the practice of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations. The goal is to reduce cognitive load on development teams while maintaining security, compliance, and operational excellence.
Key distinction from DevOps: DevOps is a culture and set of practices; Platform Engineering is a discipline that implements DevOps principles through product thinking applied to internal tools.
Related Notes in This Vault
Foundations
- Accelerate - DORA metrics that platform teams should optimize for
- continuous delivery - The delivery capability platforms should enable
- CD maturity model - Framework for measuring platform maturity
- Maturity Model - General maturity model concepts
Implementation
- kubernetes - Common platform foundation
- gitops framework - Declarative infrastructure pattern
- Backstage - Developer portal / service catalog (CNCF)
- Open Telemetry - Observability standard platforms should support
Practices
- Trunk-based development - Branching strategy platforms should enable
- Canary Rollouts - Progressive delivery pattern
- batch size - Why small changes matter for platforms
Security Integration
- Supply Chain Security - Security capabilities to build into platforms
- SLSA - Supply chain security framework
- Software Bill of Materials (SBOM) - Artifact metadata platforms should generate
- shift left on security - Philosophy platforms should embody
Organizational
- eBay Velocity Initiative - Example of platform initiative at scale
- Velocity Toolbox - Tooling for developer velocity
Key Concepts
Golden Paths
Opinionated, supported paths through the platform that represent the “right way” to do things. Not mandates—teams can deviate—but deviation means less support.
Internal Developer Platform (IDP)
The sum of all tech and tools a platform team builds and maintains. Includes:
- Service catalog
- CI/CD pipelines
- Infrastructure provisioning
- Observability stack
- Security tooling
Platform as Product
Treating internal developers as customers:
- User research with engineering teams
- Roadmaps based on developer pain points
- Measuring adoption and satisfaction
- Iterating based on feedback
Thinnest Viable Platform
Start minimal. Add capabilities when teams actually need them, not speculatively.
DORA Metrics Connection
Platforms should measurably improve:
- Deployment Frequency - Self-service deployments
- Lead Time for Changes - Automated pipelines
- Change Failure Rate - Testing, canaries, rollbacks
- Time to Restore Service - Observability, runbooks
Maturity Levels
Level 1: Standardization
- Common CI/CD templates
- Shared infrastructure modules
- Basic documentation
Level 2: Self-Service
- Developer portal (Backstage)
- Automated provisioning
- Service catalog
Level 3: Optimization
- Golden paths with guardrails
- Automated compliance
- Platform analytics
Level 4: Innovation
- Experimentation infrastructure
- AI-assisted development
- Predictive capabilities
Anti-Patterns
- Ticket Ops: Platform team becomes bottleneck instead of enabler
- Mandates without Support: Requiring tools without making them good
- Building for Building’s Sake: Features no one asked for
- Ignoring Developer Experience: Optimizing for ops, not devs
Resources to Explore
- Team Topologies (book) - Platform team patterns
- platformengineering.org - Community resources
- CNCF Platforms White Paper
- Humanitec’s Platform Maturity Model
Questions This Note Raises
- How does platform engineering relate to SRE?
- What’s the right team size/structure for platform teams?
- How do you measure platform team success beyond DORA?
- When should you build vs buy platform capabilities?
Hub note created 2026-01-31 by Claude. Connects scattered platform concepts in this vault.