Yesterday closed out the Platform Engineering Foundations phase with the IDP as one synthesized artifact — self-service, golden paths, and guardrails assembled into a single system. Today opens Platform Engineering Architecture, and the right way to start is by taking that artifact apart: not "what does an IDP do" but "what is it actually built from, layer by layer." A platform that works well can look like magic from the outside — developers ask for something, it appears, correctly configured, in minutes. It isn't magic. It's four layers, each with a clear purpose, stacked in a specific order.
The four layers, top to bottom
1. DEVELOPER EXPERIENCE LAYER (self-service)
Portal, Catalog, Docs, APIs, Search, ChatOps
Purpose: make the platform discoverable, usable, delightful.
2. PLATFORM SERVICES (building blocks)
IDP Services, CI/CD as a Service, Environments as a Service,
Observability as a Service, Security & Compliance, FinOps & Cost Mgmt
Purpose: reusable services with golden defaults.
3. PLATFORM CAPABILITIES (enablers)
Automation, Templates & Blueprints, Policy Engine, GitOps,
Workflows, Secrets Management
Purpose: the automation and intelligence behind the platform.
4. INFRASTRUCTURE FOUNDATION (run everything)
Kubernetes, Containers, Cloud, Networking, Storage, Compute
Purpose: scalable, resilient, secure foundation.Running alongside all four, not stacked above or below them, is platform governance — access control, policy, standards, compliance, audit logs, cost guardrails. Governance isn't a layer a request passes through on its way up or down; it's woven through every layer, which is exactly why guardrails (Day 26) showed up as infrastructure policy, CI/CD checks, and cost controls simultaneously rather than as one central approval step.
Note
Layer 1 is what a developer sees and touches. Layers 2 through 4 are what makes layer 1 true rather than aspirational. A portal that promises self-service databases but has no automated provisioning underneath it (layer 3) and no actual compute to provision onto (layer 4) is a mockup, not a platform.
Why the layering itself matters, not just the list
The value of thinking in layers is that it tells you where a given problem actually belongs. "Developers don't know what's available" is a Layer 1 problem — fix the catalog and discoverability, not the infrastructure underneath it, which was never the issue. "Provisioning takes forty minutes" is a Layer 3 automation problem, not a Layer 1 UX problem — a nicer button doesn't make slow automation faster. Misdiagnosing which layer owns a problem is how platform teams end up redesigning a portal to fix what was actually a broken CI/CD pipeline three layers down.
| Layer | Owns | Doesn't own |
|---|---|---|
| Developer Experience | Discoverability, usability | Whether the thing being requested actually works |
| Platform Services | Reusable golden-default building blocks | The raw compute/storage they run on |
| Platform Capabilities | Automation, policy, GitOps | The developer-facing presentation of any of it |
| Infrastructure Foundation | Scalability, resilience, security of the base | Whether developers can discover or request it |
How a request actually flows through all four
1. Developer requests what they need (through portal or API) → Layer 1
2. They choose from approved templates (golden paths) → Layer 1/3
3. Platform provisions everything automatically, guardrails applied → Layer 3
4. Developer gets a ready environment and tools in minutes → Layer 2
5. They build, deploy, and iterate — platform handles the rest → all fourEvery step in that flow crosses a layer boundary, and each boundary is where a well-run platform team has already done the integration work so the developer never has to think about the seam. That integration work — making four layers behave as one coherent experience — is most of what separates a genuinely good platform from a pile of individually-fine tools nobody's connected.
Real building blocks, not abstractions
Backstage and Crossplane at Layer 1/2, Kubernetes and Terraform at Layer 3/4, Argo CD, Prometheus, Vault, and OpenTelemetry scattered across Layers 2 through 4 — the architecture isn't theoretical. Most platform teams are assembling some real subset of exactly these tools into the four-layer shape described above, whether or not they'd draw the diagram this way.
Why the outcome is "self-service for developers, control for the business"
That's the actual design target of the whole stack: developers get to move as fast as if none of the underlying complexity existed, while the business retains exactly the control, security, and cost visibility it needs — because that control lives in layers 2 through 4 and governance, not in a human standing between a developer and what they need. Reducing cognitive load (Day 23), removing friction (Day 20), and enforcing guardrails instead of gates (Day 26) all show up in this architecture as concrete layer responsibilities, not slogans.
The remaining days in this Architecture phase go deeper into specific layers — starting with Day 29's look at GitOps as the mechanism that makes Layer 3's automation trustworthy, and Day 30's look at Kubernetes as more than a scheduler: the actual foundation, Layer 4, that the other three layers get built on top of.
