Compared 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.
[deleted]
Serverless: slower and more expensive
11–20 of 733 posts
Re: Serverless: slower and more expensive
#12I 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.
Re: Serverless: slower and more expensive
#13> 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…
>Deciding to do a whole infrastructure change...
He didn't decide to do a whole infrastructure change. He just ran an experiment that was about more than just cost.
Re: Serverless: slower and more expensive
#14> 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...
Yes, it would be a much less dramatic headline if they'd used an ALB instead of an API Gateway, it shows the complexity of the AWS product offering though that someone picking up lambda for the first time didn't find this out.
They already have a classic ELB in place, so switching to an ALB wouldn't be a significant change in cost or capability (the ALB is often cheaper, though it's hard to tell in this case)
Re: Serverless: slower and more expensive
#15I 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 fo…
Agreed, let me add my 2cts :
>The whole idea of serverless is so you don't have to manage infrastructure.
...when you are validating your product/market (100 request/day is a success here).
Not everyone on HN is a core dev, tech is getting democratised. So 1 week of time dealing with servers and accounts and infra is a week not asking the right questions.
Re: Serverless: slower and more expensive
#16I 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 fo…
If they had used an ALB instead of API Gateway, the cost might well have been a 2x increase, especially given that would replace the ELB they're already using. The ALB option has it's own caveats though...
Re: Serverless: slower and more expensive
#17Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion.
We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assessments.
Even if you make the wrong decision initially, at least it will be your own decision and you will learn from it. Moreover, when it's your own decision, you will learn from it sooner because you're not going to be getting undue reinforcement from peers.
If you over-idealize thought leaders, you will tend to stick to the popular doctrine instead of listening to your own reasoning.
Re: Serverless: slower and more expensive
#18I don't understand the term or brand "serverless", to me it seems it's still using a server, meaning a fast computer somewhere running 24/7 in a datacenter.
To me "serverless" implies decentralized networking, with a DHT or some kind of network authority, meaning P2P networking at one point or another.
Am I missing something?
Re: Serverless: slower and more expensive
#19I 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 fo…
>The whole idea of serverless is so you don't have to manage infrastructure
That's one of the ideas. Serverless shines for burst-y traffic where the traffic timing is unknown. If I had known static high loads I wouldn't use serverless.
Re: Serverless: slower and more expensive
#20I don't understand the term or brand "serverless", to me it seems it's still using a server, meaning a fast computer somewhere running 24/7 in a datacenter. To me "serverless" implies decentralized networking, with a DHT or some kind of network authority, meaning P2P networking at one point or another. Am I missing something?
Of course there's still a server. What it means is that you don't have to worry about it.