We published Polls and Predictions to people watching the 2018 World Cup. We set the vote callback URL to a function on AWS Lambda.
It failed spectacularly during our load-testing because the ramp-up period was far too slow. We needed to go from 0 to 100,000 incoming requests/second in about 20 seconds.
We had to switch to an Nginx/Lua/Redis endpoint because Lambda was just completely unusable. It would have cost us $27,000/month to pre-provision 10,000 concurrent executions...
It works pretty well for tasks that are executed infrequently (no need to have a full application deployed), out of band (no need for a rapid response; we'll email you) and for tasks that can consume excessive resources (threatening other apps running on the server).
For us the perfect use case is the production of PDF reports: they aren't run that often; they can be emailed a few minutes later; and when too many of them are run at the same time, they would steal all the RAM on the server.
Not entirely true. The largest use case we see for Lambda is as the compute service for an API backend provisioned with API Gateway (so a full application backend) with synchronous responses over HTTP (so rapid response provided within milliseconds) and for mundane tasks that store data in a database just like a regular web application.
The perfect use case we see repeatedly is for high volume HTTP requests to API Gateway endpoints that trigger Lambda functions that respond in less than a second depending on what compute is running.
Reads as the thing AWS wants people to use Lambda for.
Running Lambda as a back-end is one of the most expensive options (especially when high load comes in, as a parent pointed out). So no question, that's what they want to sell.
I consult and have encountered many people who build data intake pipelines using Lambda. The most common pattern is to have Lambdas feeding into a data lake somewhere, often Redshift.
It is a very common pattern for IoT applications also and well-suited for it. The workloads are often bursty and unpredictable.
But for many things, I believe it is still preferable to stick with a traditional web app or API. It is still early days for serverless and there is a lot of hype around it. As with most hyped things, people see it as a silver bullet and don't think through the tradeoffs they are making.
From direct exposition (via API gateway) to HTTP traffic, to very spiky loads such that we don't pay for hardware in between spikes. We've also have a kind of "hybrid pipeline" that is a mix of both HTTP requests from clients and SQS messages. The HTTP part sends messages to SQS, which triggers lambdas asynchronously so we get retries for free.
Your load doesn't strike me as being out of the ordinary, I suspect you had one of the following:
- Slow start, which means AWS was unable to re-use an already warm container to run the function a second start. This is particularly true with Java, although they've massively improved it recently.
- A dependency on another service which would have caused the slow start (loading a config is a common unexpected culprit)
- You mention 2018, so at that time running a lambda within a VPC was notoriously slow to start
- You had a limit on your AWS account (default is 1k concurrent I believe)
There are an enormous number of people using Lambda's as a part of very complex workloads including customer facing platforms. Your specific use case of 100 000 incoming requests in 20 seconds is actually far more extreme than most users use cases; Lambda can do 3000 instantly and then adds more capacity over time unless you contact AWS and ask them to increase the limits in which it can do a lot more.
There are very many users of Lambda that run very high volume production workloads (billions of requests a month) and save an enormous amount of money doing so compared to traditional techniques. A lot of that saving comes from the ability to create solutions in days as opposed to weeks or even months and the fact that for most use cases the capacity exists to handle the volume most users need.
Cron is a scheduler that executes shell commands. Lambda represents the shell command itself right? What are you using to specify when something should run?
Lambda can trigger off a bunch of AWS events. One of those events types are CloudWatch events, mostly used for triggering in response to things like CPU activity or other metrics. One of the CloudWatch events you can specify are plain old Cron events:
I recently built a facade for payment gateway callbacks to put message into SQS to reduce loss of requests from main API. (Costs less than $1 per month to handle all requests and # of lost requests in the last 6 months has gone from ~15 out of ~10k to 0)
Not AWS, but I use Cloud Functions in Firebase Hosting to redirect dynamic urls to static website paths.
Of course, in this case I have to use it, because Firebase Hosting is static, so this is the only way to handle dynamic urls if the simple rules of firebase.json are not enough.
at waiterio.com we use it for plain old web services.
Essentially one service = one lambda
Like a dyno on Heroku but much cheaper and much more scalable
We used the Serverless Framework until few months ago and now we are migrating to AWS CDK
>Also, I haven't seen anybody version control lambda code, even in compliance environments, so something to investigate.
We have anything that gets deployed to lambda go through a jenkins job. Pulls code from GH and builds/uploads it to lambda. Very few people have the ability to manually edit lambda jobs through AWS. While it isn't a perfect solution, it's worked pretty well for us.
> Also, I haven't seen anybody version control lambda code, even in compliance environments, so something to investigate.
Huh, how is it any different building and deploying to anything else.
I store the code in git, build it in team city, and deploy it to S3 using octopus deploy which updates the lambda to point to the new versioned off zip.
I just want to add in about version controlling Lambda code, this is entirely possible using the available tooling with something like the Serverless Framework at serverless.com
I guess that I was expecting AWS Lambda to scale up immediately in the same way the ALB or SQS scales up with demand. That assumption was very wrong.
Edit: my AWS support rep explained it: Without pre-provisioned capacity, it would take 34 minutes to scale our Lambda functions to the peak concurrency we needed. And it would cost several thousand dollars.
Completely insane cost. Also, EFS is ridiculously expensive.
I tried Lambda for a use-case that I had in 2018:
We published Polls and Predictions to people watching the 2018 World Cup. We set the vote callback URL to a function on AWS Lambda.
It failed spectacularly during our load-testing because the ramp-up period was far too slow. We needed to go from 0 to 100,000 incoming requests/second in about 20 seconds.
We had to switch to an Nginx/Lua/Redis endpoint because Lambda was just completely unusable. It would have cost us $27,000/month to pre-provision 10,000 concurrent executions...
What is it that people actually use Lambda for?