Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

31–40 of 733 posts

Re: Serverless: slower and more expensive

#31
post #5

They'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 w…

Is there any fundamental reason for this, apart from AWS' pricing model? It seems to me that ideally, serverless should scale from extremely small to very big without too many problems.

Re: Serverless: slower and more expensive

#33
"Serverless", or "App Engine" as it was called for the few years prior the hype, actually delivers pretty good results for a range of parameters. It might even be a wider range of parameters than the ones where the results are subpar... Or not, I'm not sure how to weight the "I have a predictable base load large enough for its cost to dominate the other factors" vs the other cases. But as always - popularity of a tool is a poor predictor of fitness to particular job at hand.

Re: Serverless: slower and more expensive

#34
post #12

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 fo…

There's already serverless where you don't have to do anything with OS/servers/infra: PaaS, like Heroku.

But no, that's not Amazon, so no one cares either way (pro/contra, cheap/expensive, fast/slow, easy/hard) :|

Re: Serverless: slower and more expensive

#35
post #5

They'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 w…

I've had problems with that level of use due to cold-starts. It was mitigated by pinging it every 10 seconds with CloudFront.

Re: Serverless: slower and more expensive

#36
post #5

They'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 w…

I think the problem is that moving from Lambda/FaaS to a container-centric alternative (ECS and friends) requires a complete re-architect of your stack. Whereas starting with a simple, single container solution and organically evolving that into container-orchestration is much simpler - because the fundamental building block hasn't changed. It's all just containers.

Personally I'd like to see the industry coalesce on "serverless" containers rather than FaaS which are organised around functions being the fundamental blocks. Please just run my Docker container(s) like a magic block box that is always available, scales as necessary and dies when no longer needed.

Re: Serverless: slower and more expensive

#37
post #18

I 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?

Think of serverless as “framework-as-a-service”. Edit: why the downvote? From infrastructure, through platform, serverless is the natural evolution of the cloud to framework-as-a-service.

Re: Serverless: slower and more expensive

#38
post #25

This feels very "Serverless is cool, everyone is saving money on it, lets do the same" > I only had to add a simple config file, add one dependency and one small startup class to my existing API project. This is not the way to do it, you have to spend some time on lambda approach. Usually splitting up your code in to smaller chuncks so you don't end up with long spool up times and you can do things like keeping your…

His application runs for a total of 3 ms. So startup time is not the issue.

Re: Serverless: slower and more expensive

#39
post #12

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 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.

Bursty or not, if the aggregated number of requests per day is in millions not hundreds, AWS API Gateway & Lambda is significantly more expensive than the more traditional options.

Re: Serverless: slower and more expensive

#40
post #5

They'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 w…

I thought the point of Lambda wasn't for not so often used APIs but for APIs where you need instant autoscaling where you may need 100 servers in 2 minutes and only need them for 20 minutes.
Post reply on HN