Architecture comparison matrix

This matrix compares five architecture classes against the requirements that most often decide the choice. It is qualitative, because the honest answer to “which is cheapest” or “which is fastest” depends on your workloads, your contract and your skills. It does not name suppliers or quote prices, and a statement here is a characteristic of the class, not a promise about any product.

The matrix

Requirement	Rented dedicated	Colocation	Virtualised hosting	Private cloud	Public cloud
Control of hardware and firmware	High, within what the supplier permits	Highest: you choose and own it	Low to none	Low to moderate, by design	None
Control of operating system and software	Full	Full	Full at the guest	Full at the guest, platform controlled by policy	Full at the instance
Time to add capacity	Days to weeks	Weeks to months	Minutes to hours	Minutes, within the pool	Minutes
Elasticity	Low	Lowest	Moderate	High, bounded by the pool	Highest
Cost shape	Recurring per server	Capital plus recurring facility cost	Recurring per unit of capacity	Hardware plus platform operating effort	Metered, variable
Efficiency for many small workloads	Poor	Poor unless virtualised on top	Good	Good	Good
Efficiency for steady, heavy workloads	Good	Good	Moderate	Moderate	Often the costliest per unit
Failure domain	One server	One server, plus your facility choices	Host and shared storage	Pool, control plane and network overlay	Provider zones and regions, and your design
Effort you carry to operate it	Hardware, OS and above	Everything, including logistics	OS and above, or less if managed	Platform engineering, or less if managed	Architecture, configuration and cost control
Single-tenant isolation	Yes	Yes	Usually no	Yes by definition	Usually no, dedicated options exist
Difficulty of leaving	Moderate: a migration	Higher: hardware and logistics	Moderate	Higher if platform-specific features are used	Higher if provider-specific services are used

How to read it

Rows are not equally important to you. A row that does not matter should not be allowed to vote. The method below turns your own priorities into a comparison, and then shows you what the comparison cannot tell you.

1. List your requirements from the rows above, plus any of your own. Keep it to a handful, six or fewer.
2. Weight each from 1 to 5 by how much it matters to the business. Do this with the people who will live with the result, not alone.
3. Score each architecture from 0 to 3 per requirement, using the matrix and your own knowledge: 0 for does not meet it, 3 for meets it well.
4. Multiply and add. The weighted total shows which options fit your priorities.

A worked example

The numbers below are invented to show the method. They are not advice, and your weights will differ.

Requirement	Weight	Dedicated	Virtualised	Private cloud
Control	4	3	2	2
Elasticity	2	0	2	3
Cost predictability	5	3	2	2
Low operating effort	3	1	2	1
Weighted total (maximum 42)		30	28	27

The totals are close, and that is the useful finding. When the scores sit within a few points, the arithmetic is not the decider: scores are judgements, and a shift of one point on one row reorders the list. Settle it on the dimensions the table does not weight well: the failure domain you can tolerate, the skills you actually have, and how hard it will be to leave. Those decide whether the choice is survivable.

What the matrix cannot tell you

• Your workloads. Utilisation, peak concurrency and data size drive the economics more than any category.
• Licensing. Per-core and per-host licensing can reverse a ranking. See Windows and Linux hosting.
• The supplier. A class is not a contract. The questions to put to a real supplier are in managed infrastructure.
• The move. Getting there is a project with its own risks. Use the migration readiness planner to check where you stand before you choose a date.