I disagree with all the comments posted so far.
This should be a perfect use case for lambda, not "oh you're API is receiving more than 10M req/day? Use Elastic Beanstalk instead with an EC2 instance and ELB". This kind of comment is just to abuse the free tier that AWS provide you with.
The whole idea of serverless is so you don't have to manage infrastructure. OS patching, mucking around with Docker and and port fowarding rules are all removed once you go down the serverless route. Is it worth 8x the cost and 15% reduction in performance? The article argues no. If anything, AWS should price API GW and Serverless more competitively.
It's nice to see though that the Firecracker implementation savings has been passed down to AWS Customers.
If the article saw a 1.5-2 times increase in cost, the debate would be much more interesting.
I'm in the container camp because serverless isn't cheap and you can't have long running processes.
>The whole idea of serverless is so you don't have to manage infrastructure
Is this even achievable with Lambda though? Even with Lambda, you still have to configure your "infrastructure", just that instead of ELB and EC2, you now have to manage APIGW and Lambda, and any other "wiring" that you need to put in to do what you needed.
All in all, I can't really say Lambda is really all that "easy" considering options like AWS EB/ECS can be setup relatively easily.
> you now have to manage APIGW and Lambda, and any other "wiring" that you need to put in to do what you needed.
You know those url.py files in a django install? Those are the equivalent of ELB/APIGW thing. You don't manage those, you make them once.
Not sure where you personally draw the line between app development and infra work, but for me "request that comes on this path, calls this function", either via ELB -> backend or APIGW -> lambda, or you know, whatever you use for your django app -> a function defined in a view.py, is app, not infra.