Orchestration

Adopting containers suddenly multiplies the number of things you have to keep an eye on. A container bundles a program with everything it needs to run so it behaves the same anywhere, and because it is light and starts in seconds, teams end up stacking dozens on a single machine. Ten services running three copies each means thirty containers to look after, and each one has to be started on a specific machine, given a memory budget, and pointed at the right network.

Where each copy was running lived in someone's memory and a spreadsheet. Two payment copies on server 3, three search copies on server 4. When a container died at 3 a.m., whoever was on call got the alert, logged into that machine, checked whether it still had room, and started the container again. On the day a whole machine went dark, one person sat down and worked out by hand where each of its containers should move.

Orchestration hands that judgment to a program. Instead of a person deciding placement, you write down the state you want, and the moment reality differs from what you wrote, the tool moves reality back.

There are five jobs it takes over, and all five are the same move: compare the desired state with the current state and close the gap. The desired state itself is a short file — which program, which version, how many copies, how much memory each one may use.

1. Placement. It picks which machine runs which container, choosing on available memory and spare capacity, so you don't end up with everything crammed onto server 3 while server 4 sits idle. You can add constraints too, such as keeping three copies of one service on three different machines, and placement respects them.
2. Recovery. When a container dies it starts a replacement to get back to the count you asked for. Write down "this service always runs three copies" and the gap is filled the moment one disappears. If a machine goes down, everything on it comes back up on the machines that are left.
3. Sizing. Attach autoscaling rules and copy counts follow load — three copies up to six when processing load passes 70 percent, back down to two when it drops under 30 percent overnight.
4. Replacement. New versions go out one copy at a time instead of all at once. One of three copies switches to the new build, the tool waits for healthy responses, and only then moves to the next, so the service stays up during a release. If the new build never answers, the rollout stops there and the old one stays.
5. Addressing. Copies die and restart constantly, so their addresses keep changing. The tool gives each service a stable name, and calls to that name land on whichever copies are alive right now.

In a microservices setup — capabilities cut into separate services that ship on their own schedules — these five stop being optional. If people place ten services by hand and revive them by hand, the release speed the split bought gets handed straight back in operations.

There are three ways to not bring this tooling in.

1. Scripts you run yourself. Keep a list of servers and drive deploys and restarts from scripts. Under ten containers on two or three machines, this is cheaper. There is less to learn and less to read when something breaks. In exchange, self-healing and zero-downtime replacement are yours to build: a restart loop is maybe fifty lines, and one that drains traffic from a copy before stopping it is considerably more.
2. Serverless. Stop thinking about containers and machines at all: upload code as functions that run only when a request arrives. Placement and sizing become someone else's problem, but a function that hasn't been called in a while takes a moment to warm up, and long-running work doesn't fit the model.
3. A fixed set of virtual machines. Decide on a few virtual computers carved out of physical servers and run your programs inside them. When the count never changes and traffic is even, this is the least to manage.

All three assume the same thing: that there isn't much to manage. Two questions usually settle it. Are there more than ten separately deployed units, and how many nights a month does somebody get out of bed to restart something by hand? Cross either line and the tooling becomes the cheaper option.

Whichever way you go, write the configuration down as infrastructure as code (IaC) — declaring machines and their setup in files you execute rather than clicking through a console. Orchestration tools take desired state as files too, so the two usually arrive together.

"Three copies are declared for this service, so one dying just pages us — nothing goes down."

A desired count is written down, which is what makes recovery automatic.

"We're not at the orchestration stage yet. Eight containers is fine with scripts."

There is little enough to manage that learning and running the tool costs more than it returns.

"Releases roll one copy at a time, so shipping over lunch is fine."

Replacement is zero-downtime, so there's no need to avoid peak hours.

Pagedeck runs four services at three copies each. Theo's job isn't starting containers on machines; it's editing the file that describes the state he wants. Search traffic triples every lunch hour, and without anyone asking for more copies, the count climbs to six and settles back to three after two o'clock.

On-call wakeups dropped from about six a month to one. Containers don't die less often than they used to — they just stopped needing a human when they do.

The most common mistake is hearing "self-healing" and "autoscaling" and concluding that operations is now handled. The tool doesn't decide the desired state for you. Declare all three copies onto the same machine and it will hold that arrangement faithfully, and all three vanish together the day that machine dies — which makes it a single point of failure, the one thing whose failure stops everything. The placement judgment people used to make hasn't disappeared; it moved into a file, where a wrong decision gets maintained more reliably than before.

The belief that self-healing reduces outages is half true at best. Restarting hides symptoms. A container leaking memory and dying every twenty minutes gets revived every twenty minutes, the dashboard shows three healthy copies the whole time, and the cause sits untouched for months. That's why teams pair this with observability — instrumentation that shows from the outside what is happening inside — and watch the restart count itself, not just the copy count.