InfrastructureSubsection
DevOps
Getting a change from a developer’s machine to a running system, repeatably and without ceremony. Three topics that stack: the pipeline that decides whether a change is safe, the image format that makes "it works on my machine" a testable claim, and the scheduler that keeps the result running. Each page is about the mechanism rather than a tool’s configuration syntax, which is what transfers when you change tools.
What is inside
Every page in this group, with what each one covers.
- CI/CDStages ordered by how fast they can fail, and the rule that one artifact is built once and promoted unchanged.PipelineOne artifact
- DockerLayers, the build cache and why image order matters — plus what a container actually is at the kernel level.LayersCache
- KubernetesThe reconciliation loop as the single idea: declare the desired state and let the controller argue with reality.ReconcileDeclarative
Where to start
- No pipeline yetCI/CD. Order the stages by how fast each can fail before worrying about which tool runs them.
- Builds behave differentlyDocker. Layer order and the build cache explain most of the difference between a fast build and a slow one.
- Kubernetes feels arbitraryRead the reconciliation loop first. Every object and every controller in the system is that one idea repeated.
Elsewhere in the section
- InfrastructureInfrastructure is everything that turns code into something running that you can observe, change and roll back. This section covers 11 topics in four groups: DevOps and the pipeline that builds one artifact and promotes it unchanged, the three major clouds and how each contains a mistake, MLOps — the same problems again for a model instead of a binary — and the monitoring that makes an incident answerable at three in the morning.
- CloudThree providers, deliberately not compared by service catalogue — those converge, and a feature table is out of date the month it is written. Each page takes one durable mechanism instead: how AWS decides whether a request is allowed and how far a mistake spreads, what a boundary in GCP costs to draw, and why Azure splits the directory from the resources. Learn those three and the catalogues stop mattering.
- Release ProcessWhat happens between "the code is merged" and "a user has it" — which in a healthy team is a decision rather than an event. Three topics: how to plan a release when you cannot promise a date, which branching model your review latency can actually support, and how to write down what changed for the people it changed for.
Found this useful?
Share it with someone who is working on the same problem.