Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

51–60 of 733 posts

Re: Serverless: slower and more expensive

#51
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…

Agree with you, Lambda would make a lot more sense if it was kind of a scaffold for your application.

Say you only have 1k users and don't want to spend too much time on infrastructure, lambda is a perfect fit for it. Your application is taking off and now you have 100k: just click a button and migrate it to a Fargate/ECS. That would be the perfect world.

AFAIK the only framework that supports this kind of mindset is Zappa (https://www.zappa.io). I use it in production but never had to migrate out of AWS Lambda so I'm not sure about the pain points related to it.

Re: Serverless: slower and more expensive

#52
As I understand it, the author conducted the test on an unusually slow connection. With a roundtrip time of almost half a second. Even a typical consumer line is multiple times faster.

He states that the workload is "saving one event to the database".

And then sees 0.42s for his old solution and 0.48s for the serverless solution.

Even if the server waits for the event being written to disk before it answers the request - that should be a negligible time compared to the roundtrip time he sees.

So the "15%" only hold for his very slow connection. If he repeated the same test on a faster connection, then it could turn out the serverless architecture is not only 15% slower but multiple times slower.

If 0.40s of those "0.42s vs 0.48s" he sees are due to his slow connection, then on a fast line it would be 0.02s vs 0.08s. Then his conclusion would be "4x slower" instead of "15% slower".

Re: Serverless: slower and more expensive

#54
post #21

1350$ per month is still fraction of salary of developer. So if it saves you that fraction of your (or your colleagues) time, it is definitely worth it.

1/10 and 1/100 are both fractions. If 1/10 of the salary of a developer is saving 1/100 of that developer's time, you lost. Fractions are not equal, blanket statements about fractions are not good business practice.

Re: Serverless: slower and more expensive

#55
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…

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.

I think this is an important consideration that a lot of people miss. One of the trends of both serverless and containers it that compared to older models they are allowing smaller and smaller teams to do bigger and bigger things.

So, in certain respects it's an enabler. Context always matters.

Re: Serverless: slower and more expensive

#56
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. OS patching, mucking around with Docker and and port fowarding rules are all removed once you go down the serverless route.

If this were the reason to use Serverless, it doesn't buy you much. Ports? You set that up once and you're done forever. OS patching? You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy.

The reasons to use Serverless is the same as everything else in the cloud: 1) fast scaling, 2) sometimes it is cheaper depending on X, and finally 3) you don't have to think about where to run it.

Re: Serverless: slower and more expensive

#57
post #26

Lambda is too expensive at the moment, sure. But I think we all know that the costs will, over time, go through the floor, and in 5 years time nobody will want to create server software using anything else.

Predicting the future is a job for fortune tellers, not developers. Being sure about what will be the cost in 5 years is beyond fortune telling. Based on what I know, my company will continue to have on-premise servers and all the companies in the sector will continue to do the same. "server software" is not just Internet software, the world is larger than that.

Re: Serverless: slower and more expensive

#58
My take on AWS Lambda is that it is the perfect glue code to automate operations between different AWS services, but not really something you want to build your entire application on. Especially since you need to make Lambda-specific optimizations in your deployed function to get good a good performance/price trade-off.

Re: Serverless: slower and more expensive

#59
If you have predictable load and constant expenses then yes, lambda should cost more than EC2 ondemand, and hardware hosting should cost less than cloud. You started development on AWS, but once infrastructure become static and all tasks well known, you can migrate and find the same of even faster hardware for almost half price. Cloud gives you a lot of flexibility, serverless make flexibility almost unlimited, but it should have its price.

Re: Serverless: slower and more expensive

#60
post #49
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 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 li…

There are definitely still things you need to think about with Lambda, like how much memory you want to allocate etc.
Post reply on HN