>doesn't really consider the costs of the alternatives I loathe blog post "anti-patterns" for this reason. Our job as engineers is largely about managing trade

>doesn't really consider the costs of the alternatives I loathe blog post "anti-patterns" for this reason. Our job as engineers is largely about managing tradeoffs. And trade-offs don't come pre-packaged in a blog of dos and donts, they're specific to the constraints at hand. Just about all of these "anti-patterns" are actually freaking awesome when what they offer (and do not offer!) lines up with what you need. 1. monoliths are awesome when that's all you need. Simple to write, maintain, and deploy. 2. Orchestration lambdas are A-OK when it's all you need and your workload fits comfortably in Lambda's constraints. I swear, the 'cloud' is rotting people's brains. There's a complexity threshold where Step Functions start to pay off. It's fairly high imo. The complexities in testing and debugging it introduces are huge compared to just dropping a break point in your control script. 3. This one is sane 4. Calling this an anti-pattern is again wrong imo. Goodness of fit depends on context. Lambdas calling other lambdas can squeeze a helluva lot of burst CPU performance for not a lot of money. There are a lot of workloads for which this makes sense. 5. This one is stepping over dollars to pick up pennies. I agree with your take entirely. Whatever minuscule amount is saved on idle CPU time with be dwarfed by the additional dev time spent writing, deploying, instrumenting, and debugging. Classic Solutions Architect wankery.