A compute platform must choose between reserved commitments, on-demand and interruptible capacity. How should the mix be decided?
Show the full answer Hide the answer
The principle
Match the commitment to the confidence. Capacity you are certain to use for the commitment period should be reserved; capacity you might use should be on-demand; capacity whose work can be interrupted should be interruptible.
The mistake in both directions is expensive: over-committing pays for capacity you do not use for the whole term, and under-committing pays on-demand rates for a predictable baseline.
Deriving the baseline
The reserved portion should be sized to the trough, not the average. The capacity you use at your quietest hour of your quietest day is the capacity you are certain to use, and that is what can be committed with confidence.
Anything above it is variable and should be priced as variable — which usually means the reserved portion is smaller than intuition suggests, and the discipline is to grow it as the trough rises rather than to commit to the average and hope.
The factors that complicate it
- Growth trajectory. A commitment made against today's baseline is safe if you are growing; it is a liability if you might shrink or migrate.
- Technology change, which is acute for accelerated compute: a three-year commitment on hardware that will be superseded in eighteen months is a bet on the resale of that commitment.
- Flexibility of the commitment. Commitments to spend are safer than commitments to a specific instance type, because the first survives an architecture change and the second does not.
- Architectural volatility. A team mid-migration should commit less, because the shape of its usage is about to change.
The discipline that makes it work
Review coverage and utilisation continuously, not annually. Two numbers matter: what proportion of usage is covered by commitments, and what proportion of commitments is actually used. Both drifting is normal, and correcting them is a routine finance-and-engineering activity rather than a project.
The thing that is left on the table most often
Commitments are a purely commercial change with no engineering risk, and they are routinely neglected because they belong to neither finance nor engineering cleanly. For an organisation with a stable baseline, this is one of the largest available savings for the least effort — and it requires only that someone owns it.