Hard disagree with the reasons given for "2. Orchestrator Lambda." While step functions are very useful and have a variety of uses, they're also VASTLY more exp

Hard disagree with the reasons given for "2. Orchestrator Lambda." While step functions are very useful and have a variety of uses, they're also VASTLY more expensive to run (the cost continues to go down but last I checked, 2.5x more expensive). Orchestrator lambdas are extremely useful, and given care in code, architecture, separation of concerns they can be extremely useful and very light. The author's point on this seems more like "I haven't seen this done elegantly" or "I tried this and my code became unmanageable," and doesn't provide solid evidence for an argument against them. The argument made could apply to any unit of infrastructure that contains code. I believe "4. Lambda functions calling Lambda functions" speaks to what I believe are the author's shortcomings for #2, with the caveat that "Cost" is definitely a consideration, as waiting for a waterfall of lambda calls will incur more cost. Call-it-and-forget-it is the more cost-efficient method for lambda-to-lambda. I trend more towards pub-sub for this scenario if the call-stack is more than 2 lambdas (e.g. lambda calling one lambda, end of stack). The author doesn't mention SNS curiously, which would suggest some inexperience in this theater. SQS can be used if payload process explicitly calls for the capabilities of SQS, but bare SNS is much more suited to light pub sub duty. Overall, this seems like a rather reductionist article written for the SEO keywords rather than content. Anyone happening across this should deep dive "the why" behind each of the claims before taking it at face value. And I wish the article stated that at the very top.