Platform Engineering: Building Internal Developer Platforms

Platform engineering is the discipline of building and maintaining self-service infrastructure platforms that enable development teams to deliver software faster. It emerged from the realization that "you build it, you run it" doesn't scale without proper abstractions.

Why Platform Engineering

Problem	Platform Solution
Every team reinvents deployment pipelines	Standardized golden paths
Developers wait on ops tickets for infrastructure	Self-service provisioning
Inconsistent security and compliance	Guardrails baked into the platform
Cognitive overload on developers	Abstracted complexity
Shadow IT and tool sprawl	Curated, supported tooling

Internal Developer Platforms (IDPs)

An IDP is the sum of all tech and tools that a platform team provides to developers:

Core capabilities:

Infrastructure provisioning: databases, queues, storage -- via self-service
Environment management: create, clone, and tear down environments on demand
Deployment pipelines: standardized CI/CD with best practices built in
Observability: pre-configured dashboards, logging, and alerting
Service catalog: discover and consume internal APIs and services
Documentation: centralized, searchable, up-to-date technical docs

Platform as Product

The most successful platform teams treat their platform as an internal product:

Users are developers -- understand their needs through interviews and surveys
Product roadmap -- prioritize features based on developer pain points
SLAs -- define availability and support commitments
Onboarding -- smooth first experience with golden paths and templates
Feedback loops -- regular check-ins, NPS surveys, office hours
Measure adoption -- track usage, not just availability

Tool Landscape

Tool	Category	What It Does
Backstage (Spotify)	Developer portal	Service catalog, docs, scaffolding, plugin ecosystem
Crossplane	Infrastructure control plane	Provision cloud resources via Kubernetes CRDs
Humanitec	Platform orchestrator	Score-based workload specification, dynamic config
Port	Developer portal	Internal developer portal with self-service actions
Kratix	Platform framework	Composable platform-as-a-product on Kubernetes
Terraform/OpenTofu	IaC	Infrastructure provisioning with modules as building blocks

Team Topologies and Platform Teams

The Team Topologies model (Skelton & Pais) defines four team types:

Stream-aligned teams: deliver value on a product or service
Platform teams: provide self-service capabilities to stream-aligned teams
Enabling teams: help stream-aligned teams adopt new practices
Complicated subsystem teams: own complex domains requiring specialist knowledge

The platform team's goal is to reduce cognitive load on stream-aligned teams. The platform should make the right thing easy and the wrong thing hard.

Golden Paths

Golden paths are opinionated, supported routes for common development tasks:

New service template: pre-configured repo with CI/CD, observability, and deployment manifests
Database provisioning: one-click database creation with backups, monitoring, and access control
Environment creation: spin up a full environment from a PR for testing
Incident response: automated runbook execution from the developer portal

Golden paths are recommended, not mandated -- teams can deviate, but they lose platform support.

Maturity Model

Level	Description
1 - Ad hoc	No platform team, each team manages their own infrastructure
2 - Standardized	Shared CI/CD pipelines, basic templates, some documentation
3 - Self-service	Developers can provision infrastructure without tickets
4 - Optimized	Data-driven platform decisions, automated governance, high adoption
5 - Product	Platform has a roadmap, SLAs, user research, and continuous improvement

Resources

:::