What Orchestration Does

The last topic ended with a problem: too many containers, across too many servers, for any person to manage by hand. The answer is to hand that whole job to a piece of software. An orchestrator is software that manages your containers for you — it decides which server each copy runs on, keeps the right number of them alive, and replaces any that fail, all without a human watching.

Here is the key shift in how you work with it. You don't give it a list of steps to perform. You tell it the result you want — "run five copies of Pageturn" — and it figures out how to make that true and keep it true. Kubernetes is the best-known orchestrator, and this is the idea at its core.

Desired staterun 5 copies

→

Scheduleplace on servers

→

Watchcompare to goal

→

Reconcilerestore the goal

You declare the goal, not the steps

The way you talk to an orchestrator is called declarative: you declare the desired end state, and the orchestrator works out the actions needed to reach it. You say "I want five copies running"; you do not say "start a copy, now start another, now check the first one." This is the same idea you'll meet again with infrastructure as code in the next chapter.

That distinction matters because the world keeps changing — servers fail, copies crash, traffic shifts. A fixed list of steps would be wrong the moment something moved. A declared goal stays correct: no matter what happens, the orchestrator's job is to keep reality matching the goal.

Scheduling: deciding what runs where

The first thing the orchestrator does with your goal is scheduling — placing each copy onto a server that has room for it. It knows how much memory and processing power each server has free, and it fits the copies in accordingly, like a host seating parties at the tables that can hold them.

You never have to think about which server gets which copy. You asked for five copies; the orchestrator quietly spreads them across the available servers and remembers where each one went.

Self-healing: replacing what dies

This is the part that feels almost magical the first time you see it. The orchestrator is always comparing the real number of running copies against your goal. The instant a copy dies — its server fails, the program crashes — it notices the count has dropped to four and starts a fresh copy to bring it back to five. That automatic repair-by-replacement is called self-healing.

Be precise about what this does and doesn't do. Self-healing replaces a dead copy with a new one; it does not fix a bug in your code. If Maya ships a version of Pageturn that crashes on startup, the orchestrator will dutifully restart it, watch it crash again, restart it again — a loop, not a cure. It restores the right number of copies; it cannot repair broken software.

Scaling: matching the number of copies to demand

The same machinery that keeps five copies alive can also change that number. When traffic to Pageturn climbs on a busy evening, the orchestrator can add copies to handle the load; when things quiet down overnight, it can remove copies so you're not paying to run more than you need. That adjusting of the count up and down is called scaling.

Because you only ever declare the goal, scaling is just a change to that goal — "make it eight copies now" — and the orchestrator does the placing and starting to get there. The next topic looks at the trickiest version of changing copies: swapping them all for a new version without the site going down.