Lambda’s success was never about bursty workloads, it’s the elastic event driven compute model it enables.
Yes only paying for the compute you actually use is great, but so is having basically limitless compute power (your wallet willing) without the ops overhead and system maintenance.
Cold starts have been a problem fire a while, and while there many be a better way than this long term, ultimately to some degree the solution will always be keeping a function warm. And that’s ultimately compute, and aws is not likely to give that away.
Honest question not being sarcastic: if this cold start latency is so important why chose function over elastic beanstalk or other auto-scaling type system?
Answer could help us try something new. We currently use large google app engine 'apps' after failing to get functions to scale quick enough (and hit limits). we have SUPER bursty traffic that needs to scale up to hundreds of instances very fast.
> if this cold start latency is so important why chose function over elastic beanstalk or other auto-scaling type system?
Pricing! It depends on the application, but there are some use-case where Lambda is way cheaper, so if we can also partially solve cold start latency, why not?
Way cheaper given a particular workload and access pattern*, Lambda is not magical and its pricing is tricky to figure out until you have something running.
You can continue to pay only for what you use and handle super bursty workloads. But there is no free solution to cold-start if you don't see the future. People needing consistent latency were already doing something similar to keep the containers alive or they just avoided to use Lambda. So I think it's a step forward.
Now this is like throwing your hands up and saying the users bursts are too big for AWS.