Cloud-Native Architecture: Containers, Schedulers and the Control Loop
A deployment is described as a desired state and a controller works continuously to close the gap. Containers make a process portable, a scheduler decides where it runs, and the control loop is what turns a crashed replica into a replaced one with nobody being paged.
What a learner can do afterwards
- Say what a container isolates and what it shares with the host
- Describe the reconcile loop and why it is written to be safe to run repeatedly
- Explain why declaring the desired state beats issuing the steps to reach it
1 · Read
Cloud-native programs split work into microservices: many small services that each do one job and talk over the network. That is the opposite of a monolith, where every feature lives in one big codebase. Each small service can be copied, moved, or restarted alone, which fits a cloud of replaceable machines.
Containers make a process portable by isolating it while still sharing the host underneath. A scheduler then decides where copies run, placing them wherever room and rules allow. When load shifts or a machine dies, placement simply changes instead of the service dying with its box.
A deployment is described as a desired state, and a controller works continuously to close the gap. If a node dies, the loop notices a missing replica and starts a replacement with nobody being paged. Declaring the end state beats issuing steps, because the loop re-derives the steps every round.
Write your reconcile loop so repeats do no harm. Each pass should compare actual against declared state and nudge only the difference. A loop safe to rerun heals crashes, absorbs moved copies, and survives its own retries.
Split into services, declare the desired state, and let a repeat-safe loop enforce it.
2 · Watch
Take it off screen
Where it sits
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.