[lysergic]

During my 3 years as a backend developer at my current job I've seen a lot of application of "serverless" stuff from AWS, and I've also used quite a lot of those services myself.

Personally I would never use something like Lambda for compute, unless it's something that needs to integrate between another AWS service and something else (likely also a service.)

Also it seems like the "serverless" hype started (atleast at my employer), because some higher ups didn't trust the developers in my department, when they first had an AWS account provisioned.

My general feeling about picking the right tool to solve a problem is to, firstly, pick the problem apart. Then you can evaluate technologies that can solve your problem. This includes code that you already own and it should most likely be this one that you pick. After that you can start to look at other technologies to bring in.

Arguably it's nice that with AWS you can spin something up relatively quickly, however sometimes I'm also stumped by their limitations and what workarounds that seems to pop up as a result of that.

[blq10]

The big place it shines for compute tasks is workloads with high variability.

As long as you can select a p99 for timeouts that's sane, lambda does a really good job handling highly heterogeneous workflows in general.

So if a request could take 10ms or multiple minutes depending on Reasons(TM) - lambda makes a lot of sense because you don't have to overprovision for theoretical peak demand, and a swamp of expensive requests is isolated from your cheap requests.