In architecture workshops, the temptation is strong to compare platforms by feature list. In the field, the trade-off is more concrete: what complexity can the team absorb without degrading service continuity?
The signal to look at first
Operational fatigue is often the deciding factor, well before the elegance of the target architecture.
Common signs of a platform that has become too heavy:
- rising MTTR,
- increased post-change incidents,
- dependency on two or three key individuals,
- runbooks rarely reliable under real conditions.
When these signals appear, "richness" sometimes becomes debt.
What simplicity brings
A leaner architecture often reduces:
- diagnostic time,
- on-call uncertainty,
- variability between sites,
- cognitive load during periods of change.
This is less visible than a new feature. But it's what protects production.
What you lose, and must acknowledge
Simplifying also means making concessions:
- fewer native options,
- sometimes more surrounding procedures,
- a more progressive transition trajectory.
A mature trade-off doesn't ignore these losses. It names them and compensates for them.
Position
I prefer a platform that's slightly less impressive on paper but operated cleanly by the team, over a "perfect" platform that becomes fragile under the slightest stress.
Architecture is a technical subject. It's also a matter of organization, governance, and operational humility.