This is interesting, thanks for sharing. Was a bit confused about lambda.
So this would be cheaper than just having an EC2/DO instance running flask with a couple of endpoints?
So this would be cheaper than just having an EC2/DO instance running flask with a couple of endpoints?
You pay for EC2/DO even if your app isn't used. With JAWS, you pay only when your app is used.
Here is Lambdas pricing FYI: https://aws.amazon.com/lambda/pricing/
However, the benefit here is that you don't have to provision to peak capacity needs + (some safety fudge factor), thereby having paid for, but idle capacity.
It's a very intriguing proposition for new services where you may not be able to optimize costs as much for fear of losing up time, but I'm sure it makes a lot of financial sense for AWS. Nothing stopping this from being a win/win though.
Getting bogged down in managing servers, or a fleet of instances, or the devops stack to automate a fleet of instances; it's all a time sink with either an actual cost or at the very least an opportunity cost, orders of magnitude beyond that $10/month.
This is especially true for organisations where provisioning an instance requires an epic chain of approvals "because it's a server". Unfortunate but all too common.
Of course if you were planning to become (or already are) a competent devopsy admin then provisioning instances is not necessarily a waste of your time. For everyone else, platform-as-a-service such as Lambda can be an huge win. Sure, there's still a tipping point but it's much greater when time, rather than simply price, is considered.
On the other hand, and contrary to the Amazon-is-scalping-me gripes I hear on HN all too frequently, my experience has consistently been that AWS want you to minimise costs due to design. Every well-run business knows the long-term virtuous cycle of satisfied & continuing customers far outweighs a short-term revenue grab.
ObDisclosure: I am a former AWS architecture manager but do not speak on behalf of my ex-employer.