BUILD THE PLATFORM.
DON'T BECOME THE PLATFORM.
Platform engineering is the discipline of building reliable, repeatable infrastructure that allows engineers to ship software without becoming infrastructure specialists.
What platform engineering actually means.
Platform engineering is not simply Kubernetes.
It is not Terraform. It is not CI/CD. It is not building another internal dashboard.
A platform is the combination of infrastructure, automation, security, observability and developer experience that creates a reliable path from source code to production.
INFRASTRUCTURE
+
AUTOMATION
+
SECURITY
+
OBSERVABILITY
+
DEVELOPER EXPERIENCE
How we got here.
BARE METAL
Physical machines, manually configured operating systems, static networks and hand-managed applications.
VIRTUALISATION
Servers became workloads. Capacity became software. Infrastructure became easier to reproduce.
CONFIGURATION MANAGEMENT
Shell scripts evolved into declarative configuration, configuration management and repeatable provisioning.
CLOUD
Compute, storage, networking and identity became programmable infrastructure.
CONTAINERS
Applications became portable units with explicit dependencies and predictable runtime environments.
KUBERNETES
Scheduling, service discovery, orchestration and declarative reconciliation moved into a common platform.
GITOPS
Desired state moved into version control and deployments became automated reconciliation.
PLATFORM ENGINEERING
The infrastructure itself becomes a product consumed by developers.
Infrastructure complexity eventually becomes developer complexity.
A modern engineering organisation may expose developers to dozens of infrastructure systems.
- Cloud accounts
- IAM
- Networking
- Load balancers
- DNS
- Container registries
- Kubernetes
- Databases
- Secrets
- Monitoring
- Logging
- CI/CD
- Infrastructure as Code
If every developer must understand every infrastructure system to deploy an application, the platform has failed to abstract the right complexity.
Treat infrastructure like a product.
A platform has users.
Those users are developers, engineering teams, operations teams and sometimes security teams.
Their experience matters.
Discoverable.
Documented.
Predictable.
Automated.
Observable.
Secure by default.
Difficult to misuse.
Make the right thing the easy thing.
A golden path is a supported, opinionated route through the platform.
It should remove unnecessary decisions without preventing engineers from making informed exceptions when required.
→ Repository
→ CI pipeline
→ Container build
→ Registry
→ Kubernetes deployment
→ DNS
→ TLS
→ Secrets
→ Monitoring
→ Logging
→ Alerts
A golden path should eliminate infrastructure decisions that provide little business value while preserving the ability to escape the path when engineering requirements justify it.
The IDP is the interface.
The underlying infrastructure can be extremely complex. The developer interface should not be.
Developer intent
"I need a production API."
Automated workflow
Repository, pipeline, image, deployment, networking, secrets and observability.
Running service
A supported production workload with the required operational controls already attached.
Kubernetes is infrastructure. The platform is what you build around it.
Kubernetes provides a powerful control plane for containerised workloads.
It does not automatically provide a complete developer platform.
- Cluster lifecycle
- Networking
- Storage
- Identity
- Secrets
- Ingress
- Observability
- Policy
- Deployment workflows
- Developer tooling
Think of Kubernetes as a platform substrate.
Platform engineering turns that substrate into a usable engineering environment.
If the platform cannot be reproduced, it isn't really a platform.
Infrastructure should be defined as code, version controlled and reproducible.
The platform should not depend on a single engineer remembering which buttons were clicked three years ago.
↓
cloud
↓
kubernetes
↓
gitops
↓
application
Git becomes the desired state.
GitOps extends the infrastructure-as-code model by making the Git repository the authoritative representation of desired state.
commit
desired state
reconcile
actual state
Reconciliation.
The system continuously works toward the desired state rather than relying on a human to remember every deployment.
A platform that cannot explain itself isn't finished.
What is happening?
CPU, memory, latency, throughput, errors, capacity and saturation.
What happened?
Events and application or infrastructure output that provide operational context.
Where did it happen?
Request paths across distributed services and their dependencies.
What needs attention?
Signals that indicate a meaningful impact to availability, reliability or capacity.
Secure by default.
Security should be part of the platform rather than a final approval gate at the end of the delivery process.
- Identity and access management
- Least privilege
- Secrets management
- Network controls
- Image scanning
- Supply-chain security
- Policy enforcement
- Auditability
- Runtime controls
- Compliance automation
The safest platform is one that makes secure behaviour the easiest behaviour.
The platform has one primary metric: developer friction.
Open ticket.
Wait for infrastructure team.
Exchange emails.
Manually configure environment.
Declare intent.
Pipeline executes.
Platform provisions.
Service becomes observable.
The platform team should not become a new ticket queue.
If every developer request requires a platform engineer, the organisation has simply moved the bottleneck.
What should the platform team own?
Platform owns
- Infrastructure primitives
- Cluster platforms
- Developer tooling
- Deployment mechanisms
- Security controls
- Observability foundations
- Golden paths
- Platform reliability
Platform should not own
- Application business logic
- Every application decision
- Every team workflow
- Every deployment manually
- Every production incident
- Developer autonomy
A platform team that becomes responsible for every application is no longer providing a platform. It has become an outsourced operations department.
The path to a platform.
MANUAL
Infrastructure is created and operated manually.
AUTOMATED
Infrastructure provisioning and common operations become repeatable.
DECLARATIVE
Desired state is represented as code.
SELF-SERVICE
Developers can consume infrastructure without requiring direct platform intervention.
PRODUCTISED
The platform is measured, documented, supported and continuously improved.
AUTONOMOUS
The platform continuously reconciles, observes, scales and remediates within defined boundaries.
How platform engineering goes wrong.
Kubernetes-first thinking
Starting with the technology rather than the engineering problem.
Too much abstraction
The platform hides so much infrastructure behaviour that debugging becomes impossible.
The ticket platform
Every developer request still requires a platform engineer.
No feedback loop
The platform is built once and then ignored.
Platform without users
Engineers optimise infrastructure while ignoring developer experience.
Golden path becomes golden cage
Opinionated defaults become mandatory restrictions without legitimate escape mechanisms.
Rules worth keeping.
02 Make the common path simple.
03 Make failure visible.
04 Keep infrastructure reproducible.
05 Secure the defaults.
06 Give developers self-service.
07 Preserve escape hatches.
08 Treat the platform as a product.
09 Measure developer friction.
10 Never hide the underlying system completely.
One system. Many layers.
↓
OPERATING SYSTEM
↓
NETWORK
↓
VIRTUALISATION / CLOUD
↓
INFRASTRUCTURE AS CODE
↓
KUBERNETES
↓
GITOPS
↓
OBSERVABILITY
↓
SECURITY / POLICY
↓
INTERNAL DEVELOPER PLATFORM
↓
DEVELOPER
↓
APPLICATION
↓
CUSTOMER
The best platform is the one engineers barely have to think about.
Good platform engineering removes unnecessary cognitive load from developers without removing engineering control.
The infrastructure remains complex. The interface does not have to be.
That is the point of the platform.