[ThePadawan]

> The consensus on the internet seems to be "serverless has its use cases" but it's not clear to me what those use cases are.

My $0.02, having used serverless before. Those use cases are:

* Very very low traffic apps. POST hooks for Slack bots, etc.. Works well!

* Someone who is an "architect" can now put "experience with Serverless" on their CV and get hired somewhere else that is looking for that keyword in their CV scans.

Those are any and all uses cases.

[mywittyname]

Agreed. The only time I reach for lambda/cloud functions is for proof-of-concepts or throwaway code (low traffic is a valid use-case though). I'm not sure about Azure Functions, but GCP Cloud Functions can have atrocious cold-start times, depending on language.

This is absolutely a huge step backwards in terms of architecture. And methinks this architect doesn't have the broadest understanding of Azure and is reaching for the easiest tool in the toolbox.

Edit: "serverless" is a broad term. There's a difference between shoehorning every microservice into a lambda-like service (bad), and migrating from a collection of VMs to a managed Azure service that does the exact same thing (can be good).

[jethro_tell]

There's tons of low traffic parts of apps. So if you're building in more of a 'microservice' architecture instead of a giant monolith, serverless has it's place. Most of your app is serving requests to users, but your signup and login flows might only run 100's of times per day and they are simple workflows, check if user exists > create new users > add password > send email verification.

Then, the email verification is checked by a second function. You click the link, it updates a field in the DB and redirects to the main page.

login is the same, we validate the creds and give a token.

And then the only infra we maintain is the stuff we have always on and serving mass requests. There's a lot of stuff that doesn't run that often that is more or less a single function and running a fleet or redundant machines for that doesn't really add value.

It just depends on how your app is designed as to if it makes sense.

[SahAssar]

If the load is so minimal for those functions and you are already running other infra for the rest of your app why would you "outsource" those functions to a serverless runtime? What do you gain besides another system you deploy to?

[liveoneggs]

config drift

[SahAssar]

What do you mean?

[liveoneggs]

By duplicating and distributing parts of your app into a bunch of distributed targets you will, eventually, accumulate drift in assumptions about your environment/partners/libraries/databases/etc

[SahAssar]

Right, so that is an argument against outsourcing low-traffic stuff to a serverless runtime, right?

[happymellon]

After using AWS Lambda and Kubernetes for different situations, I would go for Lambda everytime unless I had a compelling reason to use containers because 99% of what people have asked for is a CRUD application.

Scales down to 0, so effectively no cost overnight when used infrequently, and if you use a scripting language like Python or JavaScript the startup times are in the ms for a new instance when scaling up.

When I would use K8s would be if there is heavy processing involved, so want a language like Java or C to do the heavy lifting, image processing, encoding or encrypting and would be long running.

Disagree with serverless only being for low traffic, I've used it for a a fair amount of high traffic situations and it is great for scaling up quickly.

[thundergolfer]

> unless I had a compelling reason to use containers

AWS Lambda and Google Cloud Functions support containers.

> and would be long running.

Unless it's running 24/7, you're better of with serverless batch processing systems or you'll need scale-to-zero on your Kubernetes cluster.

[coredog64]

Yes, but…

While Lambda supports containers, you lose out one one of the largest benefits of having Amazon patch/update the runtime.

Which brings me to my opinion on the value proposition. There’s a concrete cost curve where ECS/EC2 is cheaper than Lambda in what you pay AWS, there’s a much higher inflection point where you are responsible for maintenance/operations. Under that line there’s still a place for serverless.

[happymellon]

I completely agree with you, and I didn't think that anything I said contradicted you.

Lamba works really well for reactive processing, such as supporting an API. You lose that benefit if you deal with something like Java because of the slow startup times gimps the processes.

Hence, running it in an environment which will be on constantly with consistent throughput that is just a pipeline 24/7. The scenario I've used it with was GIS and satellite image processing, which would have blown through the Lambda limits and with constant images being published meant that it was essentially processing 24/7.

[Fire-Dragon-DoL]

Do you happen to have a list of languages with lower startup times? I was trying to figure out what would work well for serverless development

[nadieyninguno1]

> * Very very low traffic apps. POST hooks for Slack bots, etc.. Works well!

I would add, that it offers an extension point / hook-in for a variety of AWS products. I can add custom functions to be called when a Cognito user is created, updated. I can add custom functions to be called to authorize routes transiting API Gateway.

At "The Firm" - we're going heavily in on AWS for our architecture - Fargate for k8s on top of the usual RDS, S3, etc.

We've begun roll-out of an external-facing API authenticated with OAuth2. Our backing store here is Cognito and our routing happens via API Gateway. We use the API Gateway's baked-in Cognito token authorizer for incoming requests, which route to pods hosted in Fargate. These pods represent a variety of projects.

As such we have two Lambda functions providing the /oauth/secret and /oauth/token endpoints for exchange of One-Time-Password for a secret token and secret token for access tokens - they experience very low N call rates (dozens?) of times per day and don't fit into any given API we host via Fargate.

[minimaul]

We use Lambda to handle lots of scale-out tasks & extensions to AWS services too - it works really well for this.

For example:

- resizing images - we can do a size per lambda all in parallel. This means we can process images quickly (with minimal latency) without having to have loads of slack memory & CPU on our backends

- queue processing - we have an app that needs to copy files from user provided URLs to S3. We do this by dumping them in a SQS queue and having a lambda fire for each queue item. Means we can do lots in parallel without filling up an EC2/fargate instance’s network port

- dynamically processing images using Lambda@Edge & Cloudfront - similar to my first one, but on the fly when requested, instead of ahead of time

[ovao]

To add a couple more good use cases for Lambda:

- To run something at deploy-time with custom CloudFormation resources. As an example, a Lambda can be invoked during each deployment to run tests. If the test fails, the stack(s) can be automatically rolled back. Tricky to get right and not often the right tool in the bag, but sometimes useful.

- As handlers for CloudWatch events. Useful for forwarding events to third-party log services, or for taking some sort of complex action based on a given event.

AWS is nearly “all in” on Lambda at this point, so it’s a good bet that if you want to hang some kind of task off an AWS service, they’ll give you a hook to fire off a Lambda. From a cost and simplicity perspective this works out well.

[chomp]

* Reduce systems footprint

* Good for "minimally dynamic" apps

* Easier in compliance/regulation-heavy environments (the kind that impose burdens on OS configuration and maintenance)

* Like you said, great for low traffic apps (the kind of things we usually build, toss over the fence to another department, and then never look at again)

* Also like you said, resume driven development

[niteshade]

Hard disagree, a couple of years back my team was running mobile game services connecting users in the millions (at peak).

We were hosted on AWS, and pretty much only used Lambda + API Gateway + DynamoDB.

[grogenaut]

In AWS that post hooks workflow also is usually "firehose" apis such as events from table writes, and they work well for streaming ETL type work.

Lambdas and workflows are like SQS and workflows. you get a few of them just use lambdas and workflows, you have a lot of them switch to a workflow engine.

[FabioFleitas]

You mention POST hooks for Slack bots - what about webhooks in general? Been thinking about moving to API Gateway -> Lambda -> SQS -> Lambda funnel for processing webhooks async & scaling easily. But this could be for higher volumes rather than low traffic.

[yamtaddle]

The really are great for little low-to-medium-traffic web-automation scripts that are small in scope. But then you can do the same damn thing with Nginx and Lua or maybe PHP. Or anything, really. CGI exists and is wonderfully suited to exactly the same use case.

[danielvaughn]

100%. Someone set up serverless at my last freelance company. Just due to the cold start, our network requests were averaging SIX seconds. This was even for requests that were just getting basic config stuff, i.e. no DB transactions required. Insanity.

[ThePadawan]

The project I was working on at the time replaced an Excel sheet in the order of hundreds of MB. The users were used to performance being miserable, so no one cared if an API request took two seconds.

I am an old school kind of engineer, and if you tell me your web requests take 2s instead of 20ms due to an architectural decision you made that doesn't have any other strong upsides, I would agree that that is insanity.