One Container Is Easy; Hundreds Is Not

Running a single Pageturn container is genuinely simple. Sam starts it on one server, checks that the site loads, and he's done. He can watch that one copy himself, restart it by hand if it ever stops, and update it whenever Maya ships something new. At the scale of one copy, a person is enough.

But that is not how real applications run. A popular app serves far more readers than one copy can keep up with, and a single copy is also a single point of failure — if it dies, the whole site goes dark until someone notices. So teams run many copies at once, across several servers. The moment they do, a fresh set of chores appears, and those chores are what the rest of this chapter is about.

Why run many copies at all?

There are two plain reasons, and they reinforce each other. The first is capacity: each copy can only handle so many readers at once before it slows to a crawl, so you run several copies and split the traffic between them. Ten copies serve roughly ten times the readers of one.

The second is survival. If you run only one copy and it crashes, your site is down until a human steps in. Run five copies across different servers, and one of them crashing barely registers — the other four keep serving readers while the dead one is replaced. Many copies turn a crash from an outage into a non-event.

The new problems that come with many copies

Once there are many copies on many servers, questions pile up that simply didn't exist with one. Which server should each new copy run on — which one has spare room? When a copy crashes at 2am, who notices, and who starts a replacement? When Maya ships a new version, how do all the copies get swapped over without the site blinking out?

These are four distinct jobs — placement, health-watching, restarting, and updating — and they all have to happen continuously, at the same time, for every copy. None of them is hard on its own. The difficulty is the volume and the fact that they never stop.

Too much for a person to do by hand

Picture Sam trying to do all of that manually. A hundred copies spread across a few dozen servers, each one able to crash at any moment, each needing the right placement and a fast restart. He would be doing nothing but watching dashboards and typing restart commands, all day and all night, and he would still miss things — people sleep, and crashes don't wait for business hours.

This is the same realization from Chapter 2: when a job is repetitive, constant, and unforgiving of a missed step, it belongs to a machine, not a person. Running many containers is exactly that kind of job.

The need for a manager

So instead of a person babysitting the copies, teams hand the whole job to a piece of software whose only purpose is to manage containers across servers. You tell it what you want — "keep five copies of Pageturn running" — and it handles the placement, the watching, the restarting, and the updating, on its own, around the clock.

That software is called an orchestrator, and the job it does is orchestration. The next topic opens it up and shows exactly what it does on your behalf.