> Implementation details don't really matter. The CloudFormation/CDK deployment of a lambda can include only the source code of the task you want to run. We don

> Implementation details don't really matter. The CloudFormation/CDK deployment of a lambda can include only the source code of the task you want to run. We don't know if AWS uses containers, an intern pressing enter, or purple unicorns. I'd argue the intern pressing enter at AWS is my infrastructure. > Not really. A lambda is your function running somewhere. Unless you explicitly create your lambdas as runnable containers instead of simply passing your handler's code, you don't know or care how are things under the hood. I feel like you took my pragmatic explanation and obfuscated it. > There is no magic or arcane wizardry involved. Never said there was, I think you think that I'm more confused than I am. I run my own serverless platform, and make use of serverless platforms from other companies. I know how they work. > then lambdas are far easier to implement and to run and to operate than modifying some server deployment to include support for a background task. In some cases, they can also be free to run. You're trying to sell me on lambdas again. I said I already make use of serverless. I just am saying there is a time and place for them, and a time where they don't make any sense. You seem to be agreeing with me, where you placed a few qualifiers on when you should use a Lambda, so I don't know why you're framing this like we're in disagreement. Maybe you're confused as to what I actually said?