4 ms·

The term "infrastructure" has kind of a loose and fuzzy definition these days. But basically I think of a serverless function as like a one-shot container that

The term "infrastructure" has kind of a loose and fuzzy definition these days. But basically I think of a serverless function as like a one-shot container that is spun up when a webhook or some other invocation method is called, handles some kind of request, puts out some kind of response, and shuts down. A container is infrastructure, ECS is infrastructure. Therefore a Lambda is some kind of ephemeral invocation-based infrastructure. It's infrastructure the whole way down. My personal take here is just that serverless functions have a time and a place in one's infrastructure, and it requires good engineering to determine where that time or place is or isn't. We use Cloudflare Workers fairly heavily, for example, to perform web redirects for some statically generated sites. It's a fairly sensical use-case for "serverless" in my opinion.

rewmie 3y ago
> But basically I think of a serverless function as like a one-shot container (...) 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. > Therefore a Lambda is some kind of ephemeral invocation-based 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. > My personal take here is just that serverless functions have a time and a place in one's infrastructure, and it requires good engineering to determine where that time or place is or isn't. There is no magic or arcane wizardry involved. If you need to peel a background task out of a server that doesn't run that often and requires no internal data other than input parameters and takes far less than 15min to run, and you're already on AWS, 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. There's also the usecase for plugging together AWS events, such as processing a file that's uploaded to a S3 bucket. If you are already neck deep in AWS, lambdas are not an arcane trick that only fit weird corner cases. You need to know what's the free tier, lambda pricing scheme, and do back of the napkin math to figure out where it makes sense to you to switch from lambdas to a dedicated service.
- starttoaster 3y ago
  > 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?
_dain_ 3y ago
>But basically I think of a serverless function as like a one-shot container that is spun up when a webhook or some other invocation method is called, handles some kind of request, puts out some kind of response, and shuts down. we used to call those "cgi scripts"

rewmie 3y ago

> But basically I think of a serverless function as like a one-shot container (...) 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. > Therefore a Lambda is some kind of ephemeral invocation-based 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. > My personal take here is just that serverless functions have a time and a place in one's infrastructure, and it requires good engineering to determine where that time or place is or isn't. There is no magic or arcane wizardry involved. If you need to peel a background task out of a server that doesn't run that often and requires no internal data other than input parameters and takes far less than 15min to run, and you're already on AWS, 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. There's also the usecase for plugging together AWS events, such as processing a file that's uploaded to a S3 bucket. If you are already neck deep in AWS, lambdas are not an arcane trick that only fit weird corner cases. You need to know what's the free tier, lambda pricing scheme, and do back of the napkin math to figure out where it makes sense to you to switch from lambdas to a dedicated service.

starttoaster 3y ago
> 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?

_dain_ 3y ago

>But basically I think of a serverless function as like a one-shot container that is spun up when a webhook or some other invocation method is called, handles some kind of request, puts out some kind of response, and shuts down. we used to call those "cgi scripts"