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.
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).
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.
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.
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.
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.
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.
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.
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
- 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.
* 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
We were hosted on AWS, and pretty much only used Lambda + API Gateway + DynamoDB.
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.
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.