Don't Panic — Cloud Architecture

Cloud architecture is the set of decisions that shapes a workload: the parts that deliver one outcome, the boundaries around them, and the behavior expected when something goes sideways. It is not a drawing competition. A diagram can show that a queue knows a database; architecture explains who owns the data, what happens when the queue stalls, and why the database has not been left to fend for itself.

The cloud supplies on-demand services, elastic capacity, and a bill that is remarkably punctual. Those are useful properties, but they do not choose the workload's requirements. Start with the outcome, the users, the data, the constraints, and the acceptable interruption or data loss. Then separate what the system does from how well it must do it. Reliability, security, performance, cost, and operability pull in different directions because apparently the universe enjoys a tradeoff.

The durable idea is boundaries. Administrative boundaries separate permissions and billing. Trust boundaries mark where identity and authorization assumptions change. Failure domains show what can fail together. Data boundaries name ownership, consistency, retention, and recovery. A component added without a requirement or risk to justify it is not sophistication; it is future work wearing a cape.

Trace one important request from identity through entry, compute, state, and response. At each hop, ask about timeouts, retries, capacity, failure behavior, telemetry, ownership, and cost. This is where hidden dependencies become visible. Redundant compute does not help if one identity service, network path, or database still holds the only door key.

State deserves the suspicious look. Replication provides another copy for availability, but it can also reproduce deletion or corruption. A protected backup preserves an earlier recovery point. RTO is the targeted time to restore a business process; RPO is the targeted amount of recent data loss. More locations do not prove recovery. Routing, capacity, data, procedures, and people all have to work at the same inconvenient moment.

Cloud service models move responsibility rather than erasing it. Managed services can reduce direct operational work, while bringing service limits, provider interfaces, pricing behavior, and migration effort. Portability also has levels: moving data is not the same undertaking as running equivalent operations on another provider.

Read the Intro for the full design path and vocabulary. Use the Slides when you need the relationships in one view. Keep the Cheatsheet nearby while reviewing a workload, and use the Practice tab to turn a brief into boundaries, recovery choices, and an architecture decision record. The point is not to predict every mishap. It is to make the important responses deliberate before the mishaps arrive with excellent timing.

Don't Panic — Cloud Architecture

Relevant careers