Cloud

Cloud is the domain where I've spent the most architectural energy over the past decade. Most of what I have to say is about the durable patterns — the ones that survive the next round of vendor announcements — and the seams where solution architecture and platform engineering meet.

What I find lasting:

• Multi-account landing zones as a security primitive. Account boundaries are the cleanest blast-radius control the major clouds offer. Any architecture that treats them as administrative inconvenience instead of security boundary leaks complexity into IAM, network, and observability later.
• Event-driven serverless for the right shapes of workload. When the work is genuinely bursty and the unit of execution is small, FaaS is still the cleanest fit. When it isn't, it's a tax. Knowing which is which is the architect's job, not the developer's.
• 12-factor and stateless containers, mostly because the alternative is a state-management problem grafted onto a deployment tool.
• Telemetry from day one. The cost of retrofitting observability onto a system that wasn't built for it is the cost of rebuilding it.

What I think is oversold:

• "Cloud-native" as if it were a commitment device. Most enterprise workloads are pragmatically hybrid for years, and the architecture should make that fact explicit rather than aspirational.
• Service-mesh complexity in shops that haven't earned it.
• Infrastructure-as-Code dogma that pretends the import path from existing infrastructure is straightforward.

This site is itself a small worked example: a Hugo static site, deployed via AWS Amplify with CDK-managed infrastructure, behind a custom domain with environment promotion. It's not enterprise-scale, but it exercises the same shape — pipeline, IaC, hosting tier, observability — at one-person scale.

Posts under this domain will mostly be opinionated takes on patterns I keep seeing fail or succeed, plus selected hands-on notes from personal AWS work.

Recent posts