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

101–110 of 733 posts

Re: Serverless: slower and more expensive

#101

Post by nevi-me »

Yes, there's probably benefit in using functions/serverless, but other than for a few endpoints where spinning an always-running VM/container/server, I've also always questioned their value.

[Anecdote time]: I've seen a product team (of otherwise clueless people) design their whole product around a serverless architecture. In one instance I heard them trying to 'solve' the authentication on each connection problem, where they could have kept connection state and authenticated a user with cookies or the like.

Assuming that some would pay for the slightly slower and more expensive serverless option; is the touted goal of scalability better than n well-optimised instances of a service, where n = 1 for most of the time?

Re: Serverless: slower and more expensive

#102

Post by zeawee »

atroche wrote: post #88
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 Rust runtime has a fast start time as well, FWIW.

Because Rust doesn't have a runtime initialization.

Re: Serverless: slower and more expensive

#103

Post by scarface74 »

cryptica wrote: post #17

Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion. We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assess…

It isn’t about “reality” it’s about trade offs. Every choice you make when it comes to infrastructure, whether to build or buy, etc comes with trade offs. The trade offs and benefits of using lambda isn’t a secret.

Re: Serverless: slower and more expensive

#104

Post by mabbo »

Serverless is the shiny new tool in the toolbox. It's great at a few very specific problems, and pretty terrible at a lot of other problems. Some people want to use it for everything because it's shiny, and they're wrong.

That doesn't mean it's not great at those tasks it's great at.

Example: I have an hourly script I need to run that downloads some files. It's been running as a lambda for 3 years without failure. It's cost me zero dollars (free tier). Even if there were no free tier, it would be less than a dollar total

Re: Serverless: slower and more expensive

#105

Post by abiro »

missosoup wrote: post #97
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'.

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.

Re: Serverless: slower and more expensive

#106

Post by eternalban »

ShinTakuya wrote: post #80
cuu508 wrote: post #39

Earlier quoted context omitted.

Bursty or not, if the aggregated number of requests per day is in millions not hundreds, AWS API Gateway & Lambda is significantly more expensive than the more traditional options.

Not if you have to serve 1 million requests in one second (with low latency) and then don't get any requests for the rest of the day. On the contrary, traditional options will probably end up costing a lot more since you'll need to have them ready in advance to serve the requests instantly and so you could be paying for the entire day of capacity or at least several hours.

So possibly a good fit for IoT.

Re: Serverless: slower and more expensive

#107

Post by joelthelion »

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.

Re: Serverless: slower and more expensive

#108

Post by scarface74 »

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…

You’re always locked into your infrastructure. People don’t willy nilly change their infrastructure once they reach a certain size any more than companies get rid of their six figure Oracle infrastructure just because a bushy tailed developer used the “repository pattern” and avoided using Oracle specific syntax.

And the “lock-in” in lambda is over exaggerated. If you’re using lambda to respond to AWS events, you’re already locked in. If you are using it for APIs, just use one of the officially supported packages that let you add a few lines of code and deploy your standard C#/Web API, Javascript/Node Express, Python/Flask/Django... app as a lambda.

Testability? Framework adoption? Stability? Industry Skills? Proven Architectures...? Are some of the other question marks I never heard a good answer for.

If you haven’t heard the “right answers” for those questions you haven’t been listening to the right people.

Lambdas are just as easy to test as your standard Controller action in your framework of choice.

Re: Serverless: slower and more expensive

#109

Post by icebraining »

Jack000 wrote: post #27
discordance wrote: post #19

Earlier quoted context omitted.

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

If Amazon has to dedicate a full server permanently to your applications, I don't see why it would cost them more or less depending on the statelessness of your application.

Re: Serverless: slower and more expensive

#110

Post by scoot »

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.

Post reply on HN