Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

Post reply on HN
Print view View original

91–100 of 733 posts

Re: Serverless: slower and more expensive

#91

Post by laumars »

philliphaydon wrote: post #77
laumars wrote: post #72

It's not as clear cut as the article describes though. For low usage stuff serverless is cheaper. For "spiky" traffic - particularly when those spikes are unpredictable - serverless is often cheaper and sometimes faster too (eg if your spikes ramp up quicker than the spin up times of virtual machines). Also AOT compiled languages like C# will run slower on lambda than pre-compiled on an EC2. You shouldn't need benchm…

> Also AOT compiled languages like C# will run slower on lambda than pre-compiled on an EC2. You shouldn't need benchmarks to work that much out - it's software development 101. This isn't true. The overhead from the article comes from API Gateway, and has nothing to do with running faster/slow via a Lambda or EC2 instance. The real performance hit in Lambda comes from cold-starts. But if you're willing to accept min…

...and the language choice has a measurable impact on the cold start time. I've measured it - as have others[1][2].

You're right that it's not just about the language runtime though. I must admit I'd forgotten about the container spin up et al as well (thankfully the recent ENI fix for VPC lambda's has been released because that was threatening to bite us hard on one project).

[1] https://mikhail.io/serverless/coldstarts/aws/languages/

[2] https://levelup.gitconnected.com/aws-lambda-cold-start-langu...

Re: Serverless: slower and more expensive

#92

Post by Legogris »

> I guess it's because Lambda has built in support for .NET Core (only 2.2 though), whereas in Beanstalk it's only supported if you use Docker and manage it yourself.

The article doesn't mention this, but I this makes me suspicious that the ELB and Lambda version might be running different versions of .NET Core, which could explain part of the performance difference.

Re: Serverless: slower and more expensive

#93

Post by brazzy »

lrem wrote: post #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 too…

> popularity of a tool is a poor predictor of fitness to particular job at hand.

It is, however, a good predictor of the ease of finding people to do the job.

Re: Serverless: slower and more expensive

#95

Post by laumars »

Multicomp wrote: post #85
laumars wrote: post #72

It's not as clear cut as the article describes though. For low usage stuff serverless is cheaper. For "spiky" traffic - particularly when those spikes are unpredictable - serverless is often cheaper and sometimes faster too (eg if your spikes ramp up quicker than the spin up times of virtual machines). Also AOT compiled languages like C# will run slower on lambda than pre-compiled on an EC2. You shouldn't need benchm…

> AOT compiled languages like C# will run slower on lambda than pre-compiled on an EC2. You shouldn't need benchmarks to work that much out - it's software development 101. However (if) you then went on to compare JIT compiled languages on lambda vs EC2 you'd notice the performance is much closer to each other. But that is what the author did. C# is not 'fully' AOT, it is JITed into MSIL on .net CLR, at least under n…

I'm getting heavily downvoted for the C# point when benchmarks do demonstrate that C# does have a measurably slower cold start time than many other language runtimes; in fact slower than every JIT language. So I'm not actually wrong on that point.

> But that is what the author did. C# is not 'fully' AOT, it is JITed into MSIL on .net CLR, at least under normal circumstances. Does elastic beanstalk use .net native style binaries somehow?

He's running .NET on EC2, so no cold start times. Elastic Beanstalk is "just" another orchestration layer (and not a good one in my personal opinion but I can see why it might appeal to some people).

Re: Serverless: slower and more expensive

#96

Post by benjaminwootton »

opsunit wrote: post #79

A comparison of Serverless to any kind of compute that uses line-item comparison and, crucially, doesn't mention Total Cost of Ownership (TCO) of the latter is flawed. To conclude that Serverless is more expensive one would have to compare the calculated TCO of managing EC2 against the line-item cost of Lambda. The article is also operating at the small change end of the spectrum where cost differences are basically…

Came here to say the same. I work in the cloud industry and see this all the time. Moving up the stack costs more in cloud costs, but less in human costs and time to market. Sure he is spending $1000 a month on this setup, but compared to the time and cost involved in managing machines and implementing something like Apigee it is not a lot.

This said, of course the optimal choice depends on your use case and profile. In some instances Lambda wins, in others EC2, in others something middle ground like Beanstalk or Fargate.

Re: Serverless: slower and more expensive

#97

Post by missosoup »

abiro wrote: post #50

PSA: porting an existing application one-to-one to serverless almost never goes as expected. Couple of points that stand out from the article: 1. Don’t use .NET, it has terrible startup time. Lambda is all about zero-cost horizontal scaling, but that doesn’t work if your runtime takes 100 ms+ to initialize. The only valid options for performance sensitive functions are JS, Python and Go. 2. Use managed services whene…

That's more steps than 'just use containers and ignore the serverless meme'.

Re: Serverless: slower and more expensive

#98

Post by dragonwriter »

hdra wrote: post #70
lucasverra wrote: post #15

Earlier quoted context omitted.

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.

Counterpoint to that though: "Serverless" isn't all that much "easier" to setup compared to traditional server setup. You still need to know how to wireup your request gateway to the correct service, you need to write your app for a serverless setup, setup security groups, etc. None of that is particularly "accessible" for someone trying to get running ASAP. I agree tech is getting democratised, but when talking abou…

> "Serverless" isn't all that much "easier" to setup compared to traditional server setup. You still need to know how to wireup your request gateway to the correct service, you need to write your app for a serverless setup, setup security groups, etc.

You only have to setup security groups if you are running lambda's in a VPC, which in the simple case (e.g., not running a cloud extension of an internal corporate network) you probably don't.

https://lumigo.io/blog/to-vpc-or-not-to-vpc-in-aws-lambda/

And, yeah, its a lot simpler than a traditional server setup without that. And even with it.

Re: Serverless: slower and more expensive

#99

Post by djm_ »

hanikesn wrote: post #38
botto wrote: 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.

That screenshot likely shows a warm startup; while they've improved recently, from personal experience .NET has the worst cold startup times of all the officially supported languages on Lambda by quite a large margin.

A source which supports that. [1]

[1]: https://medium.com/thundra/the-fundamental-problem-solving-n...

Re: Serverless: slower and more expensive

#100

Post by itsthecourier »

It depends on the load. You need to make your own calculations, for some sparse loads lambda gets the bill down up to 90%, for a load that is stable over time (like the 10 million request OP has), it makes sense to go with elastic bean or kubernetes.

You need to choose based on your load. Also, I would like to see OP slim down his app, so every lambda only has the code it needs to run and also has a permanent DB connection at least (lambda's good practices)

Post reply on HN