Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

21–30 of 733 posts

Re: Serverless: slower and more expensive

#23
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?

Of course there's still a server. What it means is that you don't have to worry about it.

Instead, you worry about the provider, and when their worries become your worries you hope you're significant enough to warrant worrying about...

Re: Serverless: slower and more expensive

#24
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?

"Serverless" is "I don't have to provision a server, or worry about where it is, or maintain it, or what OS it's running, or any of the other fiddly details."

You define a function, you hand that function to a company, and they make sure it runs when certain conditions are met. You then don't have to worry about the server.

Re: Serverless: slower and more expensive

#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 lambda warm and caching high impact parts of the code. (sometimes of course you can't cache, I know)

Having gone through this process myself with a very very large code base, it would have not worked to just slap it into serverless.

Going server less can save you money, but not by just taking your existing app and throwing it on Lambda.

Re: Serverless: slower and more expensive

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

isn't that just a limitation of the current incarnation of serverless systems? ie. serverless is only effective for burst traffic because it's expensive.

You would think that after you tailor the code to the platform and make it stateless, it would cost less for the cloud provider and not more.

Re: Serverless: slower and more expensive

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

> I'm in the container camp because serverless isn't cheap and you can't have long running processes.

Do you think you'll have the same opinion in five years time? Or how about three years?

Re: Serverless: slower and more expensive

#30
I think we you implemented a solution you never know which way is cheaper until you see the bill. Then it really becomes the chicken and egg question. Will you decide to go serverless is whether your solution will be very complicated one day. If the solution is simple already then you won't get too much benefit from serverless.
Post reply on HN