You have a collection. You need a configuration. Between those two sits a chain of decisions, and the quality of a proposal is almost entirely determined by whether that chain is visible.
The chain
Roughly, in order:
- Which statistic from the collection — average, 95th percentile, or peak
- Growth assumption over the term
- Headroom for failure of a node or a component
- Utilisation target, because running a system at 95% is not the same as sizing for 95%
- Data reduction, if storage
- Overcommit ratios, if compute
- Any platform-specific overhead: the file system’s own consumption, the storage reserved for the hypervisor, the capacity a distributed system spends on protection
Each step multiplies. A slightly generous assumption at each of seven steps compounds into a configuration that is not slightly generous.
The exercise worth doing once
Take a real collection and size it twice. Once with every assumption set to the conservative end of defensible, once to the aggressive end. Do not cheat: keep both within the range a reasonable engineer would accept.
The two answers will differ by more than you expect, frequently by a factor approaching two on storage capacity. Both are defensible. Neither is a lie. That spread is the actual uncertainty in the exercise, and every proposal contains it whether or not it is shown.
Once you have seen that spread with your own data, you will never again read a single-number sizing the same way.
What I put on the page
A short block, near the front, that reads something like:
Sized from a seven-day collection, 95th percentile, five-minute samples. Assumes 20% growth over three years, N+1 node failure headroom, 70% steady-state utilisation target, and a 2.0:1 data reduction ratio derived from the virtual machine workloads only. The reduction assumption is the largest single source of uncertainty; at 1.5:1 the usable capacity requirement rises by approximately one third.
Six lines. Everything a competent reader needs to challenge the number.
I was nervous the first time I put that in front of a customer, because it looks like admitting the answer is uncertain. It is admitting the answer is uncertain, which is true, and the reaction has been consistently positive. It reads as somebody who has done the work rather than somebody who has run a wizard.
It also does something useful competitively. When a proposal with visible assumptions sits next to one with a confident single number, the confident one now has to explain itself.
The competitive part
Every vendor’s sizing tool has defaults, and the defaults are chosen by people who benefit from the outcome. This is not a conspiracy, it is a bias, and it operates even when everyone involved is honest. The person who picked the default reduction ratio picked it from data they had access to, which was data from their own installed base.
The counter is not to distrust the tools. It is to normalise the assumptions. Run every candidate platform through the same growth figure, the same headroom, the same utilisation target, the same reduction ratio. Where a platform genuinely does something different — a file system with materially different overhead, a protection scheme with different capacity cost — account for it explicitly and say so.
What you end up with is a comparison rather than a collection of brochures. It takes longer. It is the only version worth putting in front of somebody who is about to spend money.
Where this series has been going
Four posts, one argument: the collection is evidence, the proposal is an argument built on evidence, and the joints between them should be visible. Tools will not do that for you, because a visible joint is a place where someone can push back, and tools are built to close deals.
Do it anyway. It is the whole difference between being trusted and being checked.