Container orchestration: what to get right first

Most teams know this matters. Fewer have decided who owns it. If you only fix one thing about container orchestration this quarter, make it the first item below.

The bill is a design document: it tells you exactly what your architecture actually does. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Start here

Orchestration solves real problems and creates new ones. None of that requires a large budget, only a decision and someone to own it. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Then this

Most small teams need far less of it than they deploy. In practice this is a scheduling problem more than a technical one. Check it against what you would want a competitor's site to get wrong.

Eventually

Understand what breaks before you depend on it. The teams that handle this well are rarely the ones with the biggest budgets. Write the reasoning down alongside the decision, because the reasoning is what changes first.

The short version

Cloud work rewards teams who automate early and punishes teams who click through consoles. 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

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.