DevOps Professional · Module 8: Architecture decisions and defense
Balancing Security, Cost and Reliability
Security, cost and reliability pull in different directions, and pretending otherwise produces two of them by accident. Compare designs on all three axes with shared numbers, record who chose the balance, and revisit it on schedule.
10 min reading
Objectives
- Explain why the three compete: every control costs money and moves failure
- Compare designs on all three axes with the same numbers
- Name who decides the balance and where it is recorded
- Revisit the balance when any axis moves, not on incident pressure
Why this matters
A team hardens everything and the platform becomes unaffordable to run; another optimizes cost until the first incident reveals single points of failure everywhere; a third chases nines while credentials sprawl. Each optimized one axis in isolation and inherited the others by accident. The balance is a decision with a named decider, or it is three accidents wearing a strategy's clothes. Budgets, threats and SLOs meet in one document or they meet in the postmortem.
Concepts
Each axis has its unit. Security: expected harm reduced per control (threat model ranking from M20). Cost: per-request and fixed spend on stated assumptions (M22's math). Reliability: budget consumption and recovery numbers (M18's mechanisms). A design compares on all three in one table with the same traffic and growth assumptions; the L70 lab runs this comparison across three designs under given constraints. Single-axis comparisons are how bad balances get sold.
Deciders differ per axis but decide together. Security owns the threat ranking, finance owns the spend ceiling, product owns the SLO promise; the balance meeting trades explicitly (this control costs this much and buys this much risk reduction; this saving costs this much budget burn). The ADR records the balance with its numbers and its deciders; revisits happen quarterly or when an axis moves (new threat, price change, SLO miss), never only under incident pressure.
Imbalance has signatures. Security theater (controls nobody verifies), cost surprises (bills that arrive as news), reliability debt (budgets always red): each signals which axis was ignored and which review missed it. The signatures diagnose the process, not the people; fix the review cadence that let the axis drift, not the engineer nearest the symptom.
Worked example
Three fixture designs for one service compare on one table: hardened and pricey, cheap and fragile, balanced with explicit gaps. The learner scores all three axes with shared numbers, records the chosen balance with its deciders, and names the revisit trigger per axis. No design claims all three virtues; the winner's gaps are listed, not hidden.
Common wrong move
Declaring all three top priority. Unranked priorities rank by whoever shouts last, which is incident-driven design with extra meetings. Rank explicitly, record publicly, revisit on schedule.
Quick check
An optional 4-question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Lesson feedback
No published feedback yet.
Log in and complete the lesson to leave feedback.
Exercise
Compare three fixture designs on security, cost and reliability with shared numbers, record the chosen balance with deciders, and name each axis's revisit trigger.
Pass criteria
The record shows the three-axis table, the chosen balance with deciders and numbers, and the revisit triggers per axis.