Platform Engineer Learning Path
Six stages through the pages on this site, ordered so that each one arrives after the thing it depends on - from the inner loop you are optimizing to the recovery plan you will eventually need
A route through existing material. Every entry is a page you could find on your own; the value here is the order and the reason for it.
Who This Is For
This path assumes you will operate the thing, not just choose it. That changes what is worth reading and in what order. It starts with the developer loop you are trying to improve, because every architectural decision later is judged against whether it made that loop better or worse, and a platform built without that reference point tends to optimize for the operator instead.
By the end you should be able to write an environment definition and defend its trade-offs, describe how a workspace is provisioned and torn down in your own stack, choose an isolation boundary deliberately, instrument the platform so a regression is visible before a developer reports it, and say what happens when the control plane is unavailable. Six stages, each a reasonable stopping point.
Stage One: the Problem You Are Actually Solving
Ends with you able to state, in one sentence, which loop you are shortening and what you are trading for it.
First, because it is the measurement everything else is judged against. Read it before any architecture page or you will optimize the wrong number.
The specific failure this category exists to remove. It names the symptom your stakeholders will describe to you in vaguer words.
Now the honest comparison, including what gets worse. Reading it third means you already know what the loop and the drift cost you.
Vocabulary, deliberately after the problem statement. Definitions land better when you already have something to attach them to.
The request path end to end. Close this stage with the mechanism, so the next stage is about choices rather than mysteries.
Stage Two: Environment Definitions
Ends with you able to write a definition for a real repository and explain where the specification stops and your platform starts.
The format most platforms consume, field by field. Everything downstream assumes you can read one of these fluently.
Features, multi-container stacks, and lifecycle hooks. This is where start time and isolation quietly get decided.
Concrete configurations to test your understanding against, now that the fields mean something rather than being incantations.
The alternative model, read after the mainstream one so the comparison is concrete rather than ideological.
What reproducibility costs once you try to enforce it. It reframes both previous pages, which is why it comes last here.
The copyable artifacts, useful only now that you can tell which caveat applies to you.
Stage Three: Architecture and Provisioning
Ends with you able to draw your own control plane and name every component somebody has to operate.
The control plane and data plane split. Every operational decision in stage six traces back to this diagram.
Templates as infrastructure code. Comes after architecture because a template is only meaningful once you know what it provisions into.
Where images come from, which becomes a dependency you own and a single point of failure you inherited without noticing.
The lifecycle model. Read it before snapshots, because it defines what disposable is supposed to mean.
The state that has to survive a stop. This is the compromise that makes disposable workspaces tolerable in practice.
The hardest state problem, deliberately last. It is usually the reason a clean ephemeral model does not survive contact with a real application.
Stage Four: Kubernetes and the Isolation Boundary
Ends with you able to choose an isolation boundary on purpose and say what it does not protect against.
The most common substrate for workspaces, and the scheduling behavior you will be debugging.
What changes when one cluster is not enough. Read it here rather than later, because it constrains the availability design in stage six.
Isolation as a first-class requirement rather than a side effect of the scheduler.
The stronger boundary and what it costs in start time. This is the choice a permissive pod template quietly made for you.
The same problem when the occupant is an agent rather than a person, which raises the bar on everything above.
The workload that breaks most of the assumptions in this stage, which is why it belongs at the end of it.
Stage Five: Platform Practice
Ends with you able to position this platform inside a wider developer platform rather than as an isolated tool.
The discipline this work sits inside. It arrives now because the practice makes more sense once you have built something.
An honest read on where you currently are, which is more useful after stages two through four than before them.
How a workspace becomes discoverable rather than something people ask about in chat.
Reusing one environment definition across development and pipelines, which is where the drift work in stage one finally pays off.
The same pipelines with no human at the keyboard, and the capacity implications that come with it.
Stage Six: Operate It
Ends with you able to describe what breaks, how you would see it, and what you would do at three in the morning.
Instrumentation first, because everything that follows depends on being able to see it happen.
The signals a human workspace never needed - token spend, tool calls, and runs that do nothing expensively.
Now that you can measure, this is where the inner loop from stage one gets its actual improvement.
Sizing from observed demand rather than from a vendor's calculator. It requires the data the previous three pages produce.
What happens when the control plane is not there. Read it against the architecture you drew in stage three.
The harder version of the same question, where the platform database is the thing you lost.
Turning all of the above into something a colleague can execute without you awake.
The symptom-first index, kept last as a reference rather than a lesson.
Where To Go Next
The two gaps this path deliberately leaves open
Security and Compliance Lead
Isolation appears here as an architecture choice. The policy that has to sit on top of it is a whole path of its own.
Engineering Manager
Cost barely appears above. If you are the one defending the bill, that path covers the material this one skips.
All Learning Paths
Back to the index, including the shorter reading order written for individual developers.