Container orchestration for small teams

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. Most advice about container orchestration assumes a team that does not exist at your size. Here is the version that does not.

The bill is a design document: it tells you exactly what your architecture actually does. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

What to keep

Orchestration solves real problems and creates new ones. The cost of getting this wrong is rarely visible on the day it happens. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. Getting it slightly wrong is survivable. Ignoring it entirely is not.

How we handle it

Understand what breaks before you depend on it. Small and consistent beats large and occasional here. Budget a little time for it every quarter and it never becomes a project of its own.

How to tell if yours is fine

Operability is a feature, and it has to be built rather than bought. Three things worth confirming about container orchestration before you move on:

• Someone can say what the current setup is without going to look
• Most small teams need far less of it than they deploy — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.