2 ms·

What are some use cases for lambdas? I've not got around to doing anything with them yet and I wonder what they are mostly used for.

nixpulvis 2y ago
I've heard they are good for prototyping things where you need to change APIs and spin up new stuff easily. It might be better than using a service where you're basically required to have devops. That said, you can also just spin up a VPS and use systemd to manage a service at small scale. There are also other PaaS solutions in addition to "serverless/lambda". I've heard some horror stories about "lambda" pricing as well, so I'd make sure to read into that before becoming too dependent.
- yasserf 2y ago
  Do you think having a normalization layer between serverless and server-based approaches could actually help with the issue of becoming too dependent? I find that the tight integration with providers like Azure, AWS, or CloudFront can make switching between them a very costly upfront decision. Another disadvantage of serverless is that it’s quite challenging to produce an on-premises or enterprise-ready codebase if the need suddenly arises.
  - nixpulvis 2y ago
    Being able to run things locally (like this post describes) is the only way anything should be accepted.
- myaccountonhn 2y ago
  Or you can upload a cgi script to a web host like hetzner, then you have “serverless” too.
yasserf 2y ago
I think lambdas work really well for doing things as a reaction. So for example, uploading an image to s3 could trigger a job, or having them run in parallel on a job queue since they theoretically scale way better then spinning up lots of 'job processors' to deal with influx. One of the most fringe but interesting usecases I'm aware of is it being suggested as part of co2 (and cost) reduction. The main idea is that since lambdas only run the exact amount of time needed, we don't continue running/reserving costly machine time. This is still something where research is being done and does mostly pass the responsibility to the infrastructure / PaaS solution though
crabmusket 2y ago
Here's a strong opinion semi-loosely held: The fundamental difference between functions-as-a-service and just deploying to a damn server is that you get the ability to scale very quickly. Our app has a feature which is very demanding but used infrequently. We can split the workload and spin up dozens of lambdas instantly to provide acceptable response times. Wouldn't want to have a server over-provisioned to handle that amount of scale at all times. All the other purported benefits (e.g. you can plug Lambda into S3 events) are just ways to do vendor lockin to yourself. And the ops-less-ness is cool but also you could deploy to a container platform for that.

nixpulvis 2y ago

I've heard they are good for prototyping things where you need to change APIs and spin up new stuff easily. It might be better than using a service where you're basically required to have devops. That said, you can also just spin up a VPS and use systemd to manage a service at small scale. There are also other PaaS solutions in addition to "serverless/lambda". I've heard some horror stories about "lambda" pricing as well, so I'd make sure to read into that before becoming too dependent.

yasserf 2y ago
Do you think having a normalization layer between serverless and server-based approaches could actually help with the issue of becoming too dependent? I find that the tight integration with providers like Azure, AWS, or CloudFront can make switching between them a very costly upfront decision. Another disadvantage of serverless is that it’s quite challenging to produce an on-premises or enterprise-ready codebase if the need suddenly arises.
- nixpulvis 2y ago
  Being able to run things locally (like this post describes) is the only way anything should be accepted.
myaccountonhn 2y ago
Or you can upload a cgi script to a web host like hetzner, then you have “serverless” too.

yasserf 2y ago

I think lambdas work really well for doing things as a reaction. So for example, uploading an image to s3 could trigger a job, or having them run in parallel on a job queue since they theoretically scale way better then spinning up lots of 'job processors' to deal with influx. One of the most fringe but interesting usecases I'm aware of is it being suggested as part of co2 (and cost) reduction. The main idea is that since lambdas only run the exact amount of time needed, we don't continue running/reserving costly machine time. This is still something where research is being done and does mostly pass the responsibility to the infrastructure / PaaS solution though

crabmusket 2y ago

Here's a strong opinion semi-loosely held: The fundamental difference between functions-as-a-service and just deploying to a damn server is that you get the ability to scale very quickly. Our app has a feature which is very demanding but used infrequently. We can split the workload and spin up dozens of lambdas instantly to provide acceptable response times. Wouldn't want to have a server over-provisioned to handle that amount of scale at all times. All the other purported benefits (e.g. you can plug Lambda into S3 events) are just ways to do vendor lockin to yourself. And the ops-less-ness is cool but also you could deploy to a container platform for that.