Serverless: slower and more expensive • Hacker News Board

Re: Serverless: slower and more expensive

#111

Post by scarface74 » Mon, Sep 23, 2019, 10:16 AM UTC

laumars wrote: post #95

Multicomp wrote: post #85

Earlier quoted context omitted.

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

This is no secret. C# and Java are slower with lambda than scripting languages like Python and Javascript. Whether it’s slower overall, I haven’t seen benchmarks and outside of lambda, the startup time cost is usually negligible.

Re: Serverless: slower and more expensive

#112

Post by deif » Mon, Sep 23, 2019, 10:16 AM UTC

joelthelion wrote: post #31

jedberg wrote: 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.

You're basically hiring an AWS devops position since you don't need to manage anything yourself. Great for the small startup but not so great for the already established enterprise that has some devops guys anyway.

Re: Serverless: slower and more expensive

#113

Post by philliphaydon » Mon, Sep 23, 2019, 10:16 AM UTC

laumars wrote: post #91

philliphaydon wrote: post #77

Earlier quoted context omitted.

> 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/coldst…

That first link makes no sense. The C# is not reflective us my real-world usage in the slightest bit. The 2nd link is more accurate to my experience, and obviously contradicts the first link.

I haven't tested the new VPC stuff yet to know what the impact is.

https://aws.amazon.com/blogs/compute/announcing-improved-vpc...

Re: Serverless: slower and more expensive

#114

Post by rdsubhas » Mon, Sep 23, 2019, 10:17 AM UTC

This is how a conversation with a colleague who were enthusiastic about Serverless, and who's company was mostly on Java/JVM stack went:

Colleague: Lambda is awesome, we can scale down to zero and lower costs! We love it! We use cool tech!!

Me: What did you do about JVM warm up?

Colleague: We solved it by having a keepalive daemon which pings the service to keep it always warmed up.

... Me thinking: Uhh, but what about scale down to zero?

Me: What do you do about pricing when your service grows?

Colleague: We use it only for small services.

... Me thinking: Uhh, start small and STAY SMALL?

Me: How was performance?

Colleague: It was on average 100ms slower than a regular service, but it was OK since it was a small service anyway.

... Me thinking: Uhh, but what about services who _depend_ on this small service, who now have additional 100ms times to comprehend with?

Overall, I think his answers were self explanatory. Lambda seems to be a fast prototyping tool. When your service grows, it's time to think how to get out.

Re: Serverless: slower and more expensive

#115

Post by abiro » Mon, Sep 23, 2019, 10:20 AM UTC

joelthelion wrote: post #107

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…

> 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. Shouldn't this not be a problem if you're doing 10 million requests a day? If you have enough requests, your lambdas should stay hot most if not all the time.

If you have 10m requests uniformly distributed, then yes it’s less of a problem, but that’s unlikely. (Even then lambda containers will be recycled multiple times throughout the day, so there is still a small penalty.)

Re: Serverless: slower and more expensive

#116

Post by scarface74 » Mon, Sep 23, 2019, 10:21 AM UTC

pojzon wrote: post #75

einaregilsson wrote: post #62

Earlier quoted context omitted.

Yeah, that would have been a much better fit. I just didn't know you could put ALB in front. (Also, a "load balancer" in front of serverless... , and yes I know load balancer do more than load balance.) I mainly went with API Gateway since that's the default setup the serverless framework uses.

For AWS it was november 2018 when it was annanced. Still a pretty new thing if you ask me. Many Cloud Architects still dont understand all pros and cons of this solution.

One con is that using an application load balancer with lambda restricts you to 1MB requests (and responses?) as opposed to 10 with APIGW. Lambda itself has a 6Mb limit.

Re: Serverless: slower and more expensive

#117

Post by scarface74 » Mon, Sep 23, 2019, 10:23 AM UTC

pas wrote: post #34

tedk-42 wrote: 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) :|

Heroku is not Serverless in the modern definition of the word and doesn’t Heroku run on AWS?

Re: Serverless: slower and more expensive

#118

Post by LunaSea » Mon, Sep 23, 2019, 10:24 AM UTC

nailer wrote: post #89

holografix wrote: post #48

Disclaimer: I work for Salesforce, Heroku’s parent organisation. I have had so many conversations with devops managers and developers who are individual contributors and the Lambda hype reached frothing levels at one point. Contradictory requirements of scale down to zero, scale up infinitely with no cold starts, be cheap and no vendor lock in seemed to all be solved at the same time by Lambda. Testability? Framework…

> Testability? Serverless is specifically a stateless paradigm, making testing easier than persistent paradigms. > Framework adoption? Generally we use our own frameworks - I do wish people knew there was more than serverless.com. AWS throw up https://arc.codes at re:Invent, which is what I'm using and I generally like it. > Stability? Industry Skills? Proven Architectures...? These are all excellent questions. GAE,…

> Serverless is specifically a stateless paradigm, making testing easier than persistent paradigms.

No because Lambdas are proprietary which means you can't run it in a CI or locally. Also, it becomes stateful if it pulls data from a database, S3 or anywhere else on AWS which it almost always does.

> Serverless isn't much younger than say, node.js and Rust are.

AWS Lambdas which I consider to be the first widely used Lambda service was was released in April 2015 which is 6 years after the release of Node.js. Also, Node.js is way more popular and mature than Lambda solutions.

Overall Lambdas are only useful for small, infrequent tasks like calling a remote procedure every day.

Otherwise, things like scheduling, logging, resource usage, volume and cost make Lambdas a bad choice compared to traditional VPSs / EC2.

Re: Serverless: slower and more expensive

#119

Post by scarface74 » Mon, Sep 23, 2019, 10:24 AM UTC

tedk-42 wrote: 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…

Docker can also be serverless and gets rid of all the limitations of lambda - Fargate.

Re: Serverless: slower and more expensive

#120

Post by missosoup » Mon, Sep 23, 2019, 10:27 AM UTC

abiro wrote: post #105

missosoup wrote: post #97

Earlier quoted context omitted.

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

I don’t think anybody advocates for rewriting all existing projects as serverless. But if you’re starting a startup, going all in on serverless will let you deliver better products faster. If Paul Graham’s Beating the Averages would be written today, the secret weapon would be serverless, not Lisp.

> going all in on serverless will let you deliver better products faster

Can you show some empirical evidence that supports this? In my experience this is another nebulous serverless hype claim that doesn't withstand scrutiny.