Comparing the architectures honestly

Intermediate⏱ ~17 minceph

What you'll learn

Apply a decision framework to the architecture choice
Weight the criteria for a specific situation
Recognise when the answer changes
Document the decision and its assumptions

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

The choice is frequently made on cost or on preference. A framework makes it a decision that can be revisited when the inputs change.

The criteria

Criterion	Hyper-converged	Dedicated	Weight when
Hardware cost	better	worse	budget constrained
Capacity efficiency	worse at small N	better	capacity constrained
Contention	present	absent	latency sensitive
Failure independence	worse	better	availability critical
Scaling flexibility	fixed ratio	independent	growth uncertain
Operational simplicity	one cluster	two systems	small team
Maintenance coordination	worse	better	frequent changes
Multi-consumer support	poor	good	shared service

Weighting for a situation

Small business, 3 nodes, one workload, cost-sensitive:
  hardware cost:      high weight → hyper-converged
  failure independence: low weight (accepted)
  contention:         low weight (single workload)
  → hyper-converged

Enterprise, 20 nodes, mixed workloads, availability-critical:
  failure independence: high weight → dedicated
  contention:         high weight → dedicated
  multi-consumer:     high weight → dedicated
  hardware cost:      moderate weight
  → dedicated

Growing team, 8 nodes, uncertain growth:
  scaling flexibility: high weight → dedicated
  hardware cost:      high weight → hyper-converged
  → depends on which uncertainty costs more

The third case is genuinely ambiguous, and recognising that is more useful than forcing an answer.

When the answer changes

Change	May flip the decision
Node count crossing ~12	toward dedicated
A second consumer appearing	toward dedicated
Compute and storage growth diverging	toward dedicated
Budget pressure	toward hyper-converged
Latency requirements tightening	toward dedicated
Team size shrinking	toward hyper-converged, if simpler

# the measurable signals
ceph osd df | awk 'NR>1 {n++} END {print n, "OSDs"}'
pvecm nodes | tail -n +2 | wc -l

Documenting the decision

Architecture decision: hyper-converged
Date:       2026-03-14
Scale:      6 nodes
Assumptions:
  - single consumer (the Proxmox cluster itself)
  - compute and storage growing together
  - latency requirement: p99 under 20 ms
  - budget constrained
Revisit when:
  - node count exceeds 10
  - a second consumer appears
  - latency requirement tightens below 10 ms
  - compute and storage growth diverge by more than 2x

The revisit triggers are what make the decision reviewable rather than permanent by default.

Quiz

Knowledge check · 4 questions

Q1. Why should revisit triggers be recorded with an architecture decision?

Compliance requires it, since an architecture without recorded review conditions cannot be signed off as a controlled change They determine the initial choice, because an architecture is selected by the conditions under which it would be abandoned An architecture chosen for one scale often remains at a much larger one because nothing prompts a review The change process needs them, since every configuration change is checked against the recorded triggers before approval
Q2. The architecture choice always has a clearly correct answer if the criteria are weighed properly.

True False
Q3. Review an existing architecture decision.

A hyper-converged cluster chosen three years ago at six nodes now runs eighteen nodes and serves two additional teams. No review has occurred.
Q4. Why are the ambiguous architecture cases the most important to document?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Record the architecture decision with its assumptions and explicit revisit triggers — node count, consumer count, latency requirements — or it becomes permanent by default. Document the ambiguous cases most carefully; those are the ones a future reviewer cannot reconstruct.

Cross-course references

Kubernetes: architecture decision records serve exactly this reviewability purpose
Linux: any infrastructure choice outlives the conditions that produced it