Cloud
Designing for failure, cost, and scale at once — the constraints that make cloud infrastructure interesting rather than just plumbing.
The Real Challenge
Cloud isn’t about renting servers. It’s about building systems that exploit the cloud provider’s scale without being hostage to their API changes. Every architectural decision is a tradeoff: use managed services (RDS, DynamoDB) and trade operational burden for vendor lock-in; use self-managed (Kubernetes, etcd) and own the complexity.
Cost as Architecture
The biggest mistakes I see: teams treat cost as a FinOps problem (monitor and optimize) instead of an architecture problem (design cheaper from the start). A single architectural choice—sync vs async, relational vs document, on-demand vs reserved—can swing your monthly bill by 10x.
The patterns that work:
- Right-sizing: Not “how much capacity do I need?” but “what’s the minimum viable resource envelope?”
- Tiered serving: Don’t serve every request the same way. Route 80% to cheap infrastructure; keep 20% for expensive compute.
- Cost budgets: Like performance budgets for latency, set a cost budget per feature. Make it explicit when you’re spending.
Designing for Failure
Cloud infrastructure will fail. The question is whether your architecture notices. Three layers matter:
- Fault isolation: Failure in one availability zone shouldn’t cascade to others.
- Graceful degradation: If the expensive AI inference service is down, fall back to a lighter model.
- Observability as code: Not dashboards after the fact—instrument for the failure modes you expect.
The systems that survive AWS outages aren’t the ones with the best monitoring; they’re the ones that were designed assuming outages would happen.