[norman784]

I recently learn about this term, so can someone be kind enough to explain to me ELI5 serverless usage[0], advantages over "traditional" servers and why I should/could care?

[0] by usage I mean, I still deploy my monolithic app, or just one function per route?

[erikerikson]

Not ELI5 but see https://github.com/cncf/wg-serverless/tree/master/whitepaper...

Some people go monolithic app but best practice is usually one function per route.

Traditional servers come with management overhead (e.g. defining/managing/monitoring scaling) and by using Serverless servers you avoid that overhead and optimize for good engineers which are almost always your bigger cost center.

[lf-non]

With traditional server you keep your webserver running all the time and keep paying for the underlying infrastructure whether irrespective of actual usage.

You can still spawn more instances/containers on demand and autoscale but you need to think about provisioning and how that affects your cost.

With serverless the costing maps directly to usage and scaling is (ostensibly) taken care of for you.

If you have long running workloads that anyways need preallocated infrastructure and forward planning, you likely don't gain much from serverless. If your work can be split into smaller units of executions that can be invoked on-the-fly independently, you will likely benefit from serverless pricing.

[danstewart_]

We use AWS lambda for running slower background tasks triggered from a user action on a website (eg. generating a report, clearing and rebuilding a cache, etc...).

We deploy our full monolithic app to lambda (as a docker image) and then just have a wrapper entrypoint script that dispatches the request to the appropriate module and function.

There are benefits to keeping each lambda function small but we like the benefit of deploying one lambda and being able to call any function within the monolith.

[NateEag]

To a certain extent, serverless actually delivers on the "No sysadmins required" promise that EC2 doesn't really enable (someone still has to manage your EC2 herd's configuration, even if you call that person a "devops engineer").

[my69thaccount]

1. It's trendy

2. It locks you in to a certain vendor

3. It costs more

[lf-non]

The lock-in part is increasingly untrue. Esp. if you are on gcloud, your functions are not tied to their infra at all. Eg. For nodejs you are just writing express middlewares with no real gcloud infra dependency. You can also use their build packs to run and test the functions locally. gcloud serverless infra is also built on knative so if you have teams with k8s familiarity you can run them on in-house infrastructure.

For AWS lambda I believe it was initially true, but now I believe they also support running arbitrary containers.

The costs more part is very much subject to nature of use case. If you have a lot of small services that are invoked once in a while you can benefit from serverless pricing.