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

131–140 of 733 posts

Re: Serverless: slower and more expensive

#131

Post by Angostura »

scoot wrote: post #110
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…

/disclaimer/disclosure/ When you disclose something, it's a disclosure.

Unless its a disclaimer, because the poster knows that there is likely to be bias in their post, is aware of that and doesn't want to fix that.

Re: Serverless: slower and more expensive

#132

Post by sbhn »

I’ve got downvotes for suggesting the same thing during the hype. In fact all my truths get downvoted. Read them, they are hilarious some of them.

And not only that, breaking news, serverless with aws is severe vendor lockin.

Re: Serverless: slower and more expensive

#133

Post by abiro »

missosoup wrote: post #120
abiro wrote: post #105

Earlier quoted context omitted.

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.

I don’t think it’s possible to produce empirical evidence to prove or disprove this claim, but it’s just common sense: Using managed services leads to writing less code and minimizing devops work, both resulting in more time for feature development that takes less time overall and produces higher quality service (latency, availability, etc). Then there is the added benefit of clear financial insight into the inner workings of the application (one can trace capital flows through functions) which will result in better resource allocation decisions.

Re: Serverless: slower and more expensive

#134

Post by scarface74 »

z3t4 wrote: post #53

Serverless is a cool solution looking for a problem to solve. However much I want to use it, eg. not having to manage servers myself, I can't find any use case where it would make sense.

Well, millions have. So obviously someone has found a problem it will solve...

Re: Serverless: slower and more expensive

#135

Post by laumars »

philliphaydon wrote: post #113
laumars wrote: post #91

Earlier quoted context omitted.

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

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

They don't contradict each other. They're different graphs demonstrating different workloads. You'd be surprised just how much peoples "real-world usage" can vary from one customer to another.

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

Pretty significant for high demand lambda's. Unfortunately I'm not sure how much of what I know is covered by NDA so apologies for not being more specific.

Re: Serverless: slower and more expensive

#136

Post by xwdv »

k__ wrote: post #74
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…

The community is to blame for this. If "serverless heros" are running around promoting Lambda, newcomers will use it without thinking twice...

In tech you either die a hero or live long enough to become the villain.

Re: Serverless: slower and more expensive

#137

Post by k__ »

LunaSea wrote: post #118
nailer wrote: post #89

Earlier quoted context omitted.

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

"No because Lambdas are proprietary which means you can't run it in a CI or locally."

It kinda is, but not really. You get an event object as param and often only need a few fields from it.

Also, you can run Lambda locally, AWS SAM CLI lets you run them in Docker for debugging purposes.

Re: Serverless: slower and more expensive

#138

Post by coldtea »

peterwwillis wrote: post #127
coldtea wrote: post #73

Earlier quoted context omitted.

> 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. This is "you'll always have to do X, so might as well do 10x" argument...

Who would argue that? Why would you ever want to do 10 times something just because you do it once?

Well, the "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." is close to making that argument.

Just because I have to manage patches for 'my app and it's libraries' doesn't mean also handling the OS and everything else that would already be covered by the serverless service is no biggie...

Re: Serverless: slower and more expensive

#139

Post by missosoup »

abiro wrote: post #133
missosoup wrote: post #120

Earlier quoted context omitted.

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

I don’t think it’s possible to produce empirical evidence to prove or disprove this claim, but it’s just common sense: Using managed services leads to writing less code and minimizing devops work, both resulting in more time for feature development that takes less time overall and produces higher quality service (latency, availability, etc). Then there is the added benefit of clear financial insight into the inner wo…

> but it’s just common sense

No. There's nothing common sense about it. It only seems plausible if you read the sales brochure from a cloud vendor and have no experience with all the weird and whacky failure modes of these systems and the fact that none of the major selling points of serverless actually work as advertised unless you dedicate significant engineering time to make them work - as the GP comment has demonstrated. The amount of engineering time required to make serverless work quickly catches up to or even exceeds just doing the damn thing the normal way.

And that engineering time is not transferable to any other cloud vendor, and neither is your solution now. So congratulations you just locked your business in.

Serverless only makes sense if you have a fairly trivial problem and operate on really narrow margins where you need your infra and associated costs to scale up/down infinitely.

Re: Serverless: slower and more expensive

#140

Post by pavlov »

Something about the Lambda/FaaS/serverless hype reminds me of early 2000s enterprise Java, when everyone was trying to replace code with XML configuration.

It's obviously at a different point in the stack, but the promise is similar: "Just say what you want and it magically happens" — and indeed that's the case for FaaS when your problem is small enough. But XML-configured frameworks also offered that convenience for their "happy problem space". You could get things done quickly as long as you were within the guard rails, but as soon as you stepped outside, the difficulty exploded.

I'm not convinced AWS Lambda is all that different from a web framework, it's just on a higher level. Instead of threads responding to requests, you have these opaque execution instances that hopefully will be spun up in time. Instead of XML files, you have a dense forest of AWS-specific APIs that hold your configuration. That's how it looks from the outside anyway.

Post reply on HN