A couple of days ago I published this tweet:
Some people confused my idea saying that Lambda is already Spot. I understand the position they come from. Lambda only charges per usage, it's not 'rented'.
But the idea I have for Spot is the situation when AWS has idle servers lingering around their data centers, in which they incentivize low-value workloads by lowering prices. Low revenue is better than nothing in those cases.
Workloads that wouldn't be cost-effective to run on EC2, become interesting on Spot instances.
Spot has particularities:
- AWS can terminate the instance at any moment (when someone else is willing to pay more for it), so your workload must be super fault-tolerant;
- We can bid how much we'd like to pay for each workload, so we'll use the Spot instances only when the price is low enough;
The same could happen for Lambda. We store invocations in a particular queue and integrate it with a Lambda Spot, setting a price per invocation and per GB-seconds. When the price is low enough, the Lambda platform will start pulling messages and processing them.
Under the hood, Lambda runs on Firecracker, which runs on EC2 instances. What we need is a Firecracker running on Spot Instances. They could go away on a snap, which would halt all Lambda executions, but that's fine.
Leave your suggestions in the comments. Like ❤️ the article if you like the idea 💡
Top comments (2)
Interesting! If it sat in a Lambda-Spot-only-queue, there would need to be agreement that the price boundaries actually hit your "bid price" otherwise it's possible that your functions would never rube triggered to run.
Since everyone's pay threshold is different, it would hard for amazon to set an agreed-upon price. And which functions could your application risk not run?
The biggest question I have would be, what would be the incentive for Amazon to do this? If you really need to run your code you'll run it (probably using their infra) regardless of your personal cost.
Awesome! Thanks for the clarification Renato 😊