Cloud & Infrastructure
How infrastructure actually supports software systems — how compute, storage, networking, identity and orchestration fit together, and how to design infrastructure that is secure, scalable, observable, reliable and cost-aware without adding complexity the workload never asked for.
What are you trying to deploy?
Infrastructure is derived, not chosen from a catalogue. Pick a workload and the first question is about the workload — never about a product.
What happens to a request in flight when the instance serving it is replaced?
- 1Choosing a Compute ModelVirtual machine, container, managed container platform, or functions. Six questions decide it, and every answer must come with why, what it costs, and what you would use instead.
- 2Load Balancers as InfrastructureThe Architecture domain argues why you need one. This lesson is about running it: external versus internal, L4 versus L7, health checks that tell the truth, TLS termination, and target registration that has to keep up with a deploy.
- 3Public and Private SubnetsThe difference is one line in a route table, not a property of the subnet. Which is why the useful question is not "is this subnet public" but "does this workload need a public address at all" — and for most workloads the answer is no.
- 4Health ChecksThe mechanism that decides which instances receive traffic. A check that only proves the web framework is running proves nothing; a check that verifies every dependency turns one slow dependency into a total outage.
- 5Graceful Shutdown: The 502 Spike Nobody InvestigatesDeployment starts → stop accepting new traffic → finish in-flight work → close resources → terminate. Skip the middle and every deploy drops the requests that were in progress, producing a small, regular spike of 502s that gets explained away as "just the deploy".
The learning loop
Every lesson answers this chain as explicit fields, so a lesson can never recommend something without saying what it costs.
Flagship experiences
Seven stages from one process on a laptop to a zone-redundant, autoscaled, code-defined system. Every stage names the concrete failure that forced it — nothing is added because "that is how it is done".
One API and one PostgreSQL, walked through ten infrastructure decisions. Each answer is graded and recorded as decision → reason → alternative → trade-off.
Place and connect components, then read the architecture back through structure, security and cost views. The analyzer is rule-based and every rule is printed on the page.
Kill a VM, a zone, a region, a certificate, an IAM permission, the NAT path. Predict the blast radius before you see it — and find out which signal stays green.
Git push to live traffic, hop by hop, showing the artifact, the identity acting, the network path and the rollback at every stage.
Five million users across Europe and the US. Design the whole thing, then survive six failures injected against your own decisions.
Learning modules
What is infrastructure actually for, and how do I reason about it without starting from a product name?
Infrastructure derived from the workload rather than from a catalogue: what an application needs before any service is chosen, the honest on-premises comparison, regions and failure domains, the layer stack from application down to the data center, where the provider's responsibility ends — and why complexity has to be justified.
Where does my code actually run, and which execution model fits this workload?
Compute as a resource envelope — CPU, memory, local storage, network — rather than a machine you own. Instance lifecycle, what an architecture choice reserves, and the decision between virtual machines, containers, managed containers and functions.
What am I getting when I rent a machine that is not a machine?
Hypervisors, guest operating systems and virtual hardware; the lifecycle from provision to terminate; patching as an operational obligation; immutable images versus machines you log into; and one large VM against several small ones.
How do I package a workload so the thing I tested is the thing that runs?
Containers from the operations side — the OS internals live in the Operating Systems domain. Image composition and layers, the build pipeline, why image size is an operational and security concern, registries and digests, configuration kept out of images, and where state is allowed to live.
Who keeps a hundred containers on twenty machines in the state I asked for — and do I need that?
Orchestration derived from the problem: placement, restarts, health, rollout, discovery. Kubernetes as a control loop over desired state, its core objects and why each exists, scheduling with requests and limits, OOM kills and CPU throttling, pod autoscaling — and the mandatory lesson on when none of it is warranted.
What changes when I stop managing servers, and what does that cost me?
Serverless as an execution model: event to platform to invocation to scale-down. Cold starts, runtime limits, enforced statelessness, concurrency caps, the connection problem against a pooled database, observability gaps and the cost shape that is cheap until it is not.
How does traffic reach my workload, and what is it allowed to reach in return?
How cloud constructs compose the networking fundamentals taught elsewhere: virtual networks and address ranges, public and private subnets, route tables, internet and NAT gateways, stateful security groups versus stateless ACLs, private connectivity, DNS, load balancers and the CDN edge.
Where does the data live, and which storage shape matches how it is accessed?
Object, block and file storage as three different contracts, direct-upload architectures with signed authorization, and managed databases with an honest boundary — what the provider runs, and what remains entirely yours.
Who is this workload, what is it allowed to do, and what happens if it is compromised?
The deepest infrastructure module. Identity → policy → action → resource; human credentials versus workload identity; policy anatomy and blast radius; short-lived role credentials instead of static keys; secret storage, rotation, audit and revocation; and the key hierarchy behind encryption at rest.
How do I make infrastructure repeatable, reviewable and recoverable?
Definition → plan → apply → real resources. Declarative desired state against imperative scripts, Terraform's vocabulary, state as the thing that makes it work and the thing that will hurt you, drift between the file and reality, modules that help versus abstraction that hides, and environments that differ on purpose.
How does code get from a commit to serving traffic without an outage?
Pipeline infrastructure and its identity, building an artifact once and promoting it unchanged, the four rollout strategies and what each buys, version compatibility during a rolling deploy, and shutting down without dropping in-flight work.
How does capacity follow demand, and why is new capacity always late?
Horizontal, vertical, scheduled and metric-based scaling; choosing the signal that represents workload pressure rather than the one that is easiest to read; startup time as the reason scaling lags; and health checks — including the liveness/readiness confusion that turns a deploy into an outage.
What happens when a piece of this dies, and how do we get back?
Redundancy that is actually redundant: failure domains from process to region, multi-zone and multi-region topologies, active-passive against active-active and the data problem it creates, RPO and RTO as requirements rather than adjectives, backup strategy, and the restore you have never tested.
Which infrastructure signals tell me the platform underneath the application is healthy?
Not a second observability course — the depth lives in the Observability & Performance domain. What is specific here: instance and pod health, autoscaling behaviour, load balancer target health, control-plane events, cloud service errors, audit trails and the question "who changed this infrastructure, and from where?".
What is exposed, who can reach it, and what is the blast radius?
The security overlay that every infrastructure diagram gets: public exposure with context rather than reflex, trust boundaries, encrypted links, privileged resources, and the supply chain from source through build identity to the image production actually pulls.
What does this architecture cost to run, and which line item is the surprise?
Cost as a design constraint, not a monthly report. The drivers, fixed against usage-shaped spend, idle capacity and the difference between headroom and waste, right-sizing without ignoring peaks and failover, per-service attribution, egress, and storage that ages into a cheaper tier.
What is different about running model and agent workloads?
Long-running jobs that outlive a request, model credentials as first-class secrets, tool sandboxes as isolation boundaries, accelerator scheduling and memory limits, batching and utilization, and the choice between a hosted model API, managed inference and a GPU cluster you own.
Which of this complexity does the business actually require?
Multi-cloud and hybrid taught cautiously and with their real cost, migration as inventory → dependency mapping → strategy → pilot → gradual move → validation, the five migration dispositions, and a qualitative operational-complexity score that makes "we added Kubernetes and a service mesh" visible as a decision.
Not a list of cloud services
What this domain refuses to teach, and what it teaches instead.
A NAT gateway lesson teaches outbound-only egress for private workloads. What each provider calls it is a footnote. Every claim carries a label saying how far it generalizes.
Every lesson has a required alternatives field naming something simpler and when it is the better answer. A lesson that cannot name one is teaching a default rather than a decision.
Cost material teaches shape and drivers — which meter runs, which line item surprises people. Bars are relative weights; real rates depend on provider, region, commitment and volume.
Kubernetes is a decision, not a default. Multi-region is not automatically high availability. Multi-cloud is not automatically more reliable. Serverless is not automatically cheaper. Managed does not mean zero responsibility.
The final objective is not to memorize cloud products. It is to hear “we built an application — how do we run it in production?” and reason systematically: what workload is this, what compute model fits, what network boundaries exist, what storage does it need, what identity does each workload use, how are secrets handled, how do we deploy, how do we scale, what fails, how do we recover, how do we observe it, how do we secure it, and what does it cost.