Container orchestration: the questions we get asked most

There is no clever trick in this one, just a handful of decisions worth making deliberately. The questions about container orchestration that come up most often on our calls.

Cloud work rewards teams who automate early and punishes teams who click through consoles. Doing this properly once is usually cheaper than doing it approximately three times.

Do we need to care about this?

Orchestration solves real problems and creates new ones. The cost of getting this wrong is rarely visible on the day it happens. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. In practice this is a scheduling problem more than a technical one.

How do we know it is working?

Understand what breaks before you depend on it. 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.

In practice

The bill is a design document: it tells you exactly what your architecture actually does. 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

If any of that sounds like a description of your current setup, it is fixable.