Serverless: slower and more expensive
einaregilsson.com
Serverless: slower and more expensive
1–10 of 733 posts
Re: Serverless: slower and more expensive
#2Compared to EC2. If you went bare metal hosting, it would be cheaper and faster. But more work on your end.
The point of all these levels of abstraction is it takes less work to manage. Cost and performance is always worse.
Re: Serverless: slower and more expensive
#3> For us it would have been better if we could just put a normal load balancer in front of Lambda.
This can be done.
https://aws.amazon.com/blogs/networking-and-content-delivery...
Re: Serverless: slower and more expensive
#4> To be honest I hadn't thought at all about the pricing beforehand. I just figured "Pay for what you use" sounded like it would be cheaper than paying for instances that are on 24/7.
Deciding to do a whole infrastructure change to save money without even stopping 5mins to do a quick math on the expected savings seems like a recipe for disaster.
Just switching from m1.small to t2.small would bring their costs down to $55 from $96 for the compute. Just make sure to create a monitor in case you use up all your burst capacity. Other than that a quick reservation would bring that down even further, and all of this with zero re-architecting.
Serverless is super cheap if your workload is not serving requests constantly. It's like renting a car 365 days out of the year instead of purchasing, it only makes sense if you only need it sporadically.
Re: Serverless: slower and more expensive
#5They're doing over 100rps if they're doing 10M requests a day. That's not a good use case for Lambda. If you're going to be that heavily utilized it makes more sense to run your API on EC2 or ECS/Fargate/etc.
Lambda is a good use case for when you have lots of not-often-used APIs. Lambda is a great solution for an API that's called a few times a day. It's also great for when you're first starting out and don't know when or where you'll need to scale.
But once you get to 100rps for an API, it's time to move to a more static setup with autoscaling.
Re: Serverless: slower and more expensive
#6The title is misleading, serverless is slower and more expensive for this particular use case, assuming that the author used the best practices for lambda performances.
Re: Serverless: slower and more expensive
#7> To be honest I hadn't thought at all about the pricing beforehand. I just figured "Pay for what you use" sounded like it would be cheaper than paying for instances that are on 24/7. Deciding to do a whole infrastructure change to save money without even stopping 5mins to do a quick math on the expected savings seems like a recipe for disaster. Just switching from m1.small to t2.small would bring their costs down to…
His main goal was to reduce deployment time, not to reduce costs.
It's obvious from the article that he would have even lived with a slight bump in pricing if he got that.
Re: Serverless: slower and more expensive
#8It is a great apples to oranges comparison. If you do not take into consideration that somebody has to setup and manage the instance that runs 0/24 and you do not care about availability (single instance can go down easily) then you might even say that you are comparing apples to apples.
Re: Serverless: slower and more expensive
#9> To be honest I hadn't thought at all about the pricing beforehand. I just figured "Pay for what you use" sounded like it would be cheaper than paying for instances that are on 24/7. Deciding to do a whole infrastructure change to save money without even stopping 5mins to do a quick math on the expected savings seems like a recipe for disaster. Just switching from m1.small to t2.small would bring their costs down to…
Better to use t3.small and use infinite burst
Re: Serverless: slower and more expensive
#10Compared to EC2. If you went bare metal hosting, it would be cheaper and faster. But more work on your end. The point of all these levels of abstraction is it takes less work to manage. Cost and performance is always worse.
Smoother scaling and lower entry cost as well.
It seems obvious that at scale, someone running machines for you could not be cheaper, unless they had access to technology allowing to operate at lower costs or cheaper electricity.
Renting can't be cheaper than at scale under normal circumstances. OP was beyond the breakeven point.