Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

501–510 of 733 posts

Re: Serverless: slower and more expensive

#501
post #164

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…

This is all strawman. There are valid reasons for serverless, most people choose it for reasons other than hype, and the savings and security of not self managing servers is tangible. All technology can be misused or poorly utilized, and even the best can have pathological edge cases. For the 80% or more, serverless works just fine.

[deleted]

Re: Serverless: slower and more expensive

#502
post #164

Earlier quoted context omitted.

This is all strawman. There are valid reasons for serverless, most people choose it for reasons other than hype, and the savings and security of not self managing servers is tangible. All technology can be misused or poorly utilized, and even the best can have pathological edge cases. For the 80% or more, serverless works just fine.

Not a strawman, nope. Please put the React salesmen on this list of bogus hype as well. It’s all projection and propaganda—zero substance. Here’s the proof of evil intent behind React, for example: https://news.ycombinator.com/item?id=20711598

I suspect I am more wary of Facebook than most. However, unless there is something in that linked discussion that I'm just not seeing, I don't get it.

Or perhaps your idea of "proof" and mine are just vastly different.

Re: Serverless: slower and more expensive

#503
post #457

Earlier quoted context omitted.

An example of where serverless is lovely for us : We run on AWS. We log lots of stuff to CloudWatch. CloudWatch allows you to scan for regexps (more or less) and send matching lines to a destination of your choosing. There are about 5-10 such matching events per day that we care about, and when they happen, we want an alert in a Slack channel (or email or text or PagerDuty or...). Option A: Stand up a server. Deploy…

You're using Lambda because you haven't figured out how to enable cgi-bin in Nginx?

How can cgi-bin in Nginx help in his case?

Re: Serverless: slower and more expensive

#504
Lambda is not suitable for certain workloads. It's impossible to know what is the problem in this particular case from the details provided by the author. I can give some common examples where Lambda would NOT work well:

* if the code you run has heavy initialization phase that could be amortized across multiple runs. Lambda is not a god fit because you'd do initialization for every request. Cold start latency compounds with code initialization to make the problem worse

* if the function workload involves lots of waiting for network I/O (REST APIs, lots of database calls, web crawling). In this case you'll be paying for each lambda function to wait for the network, while if you run the same workload on a single machine it will be cheaper because you can wait for many requests in parallel in different threads without consuming much resources.

Having mechanical sympathy for your workload does help.

Re: Serverless: slower and more expensive

#505
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 the selling point of AWS in general, but I wouldn't be surprised if (non-tiny) companies are still spending at least as much on AWS/etc. as they would on in-house infra. That is, they're paying for it anyway, and possibly at a premium.

Re: Serverless: slower and more expensive

#506
This makes me think of the Amazon CTO's analysis from Modern Applications on AWS where they push Serverless as the future:

"...we anticipate that there will soon be a whole generation of developers who have never touched a server and only write business logic."

Honestly, which sounds more like a nightmare than a dream. Knowing what your software runs on and how it works is critical if you want to create REALLY GREAT software.

(reference article: https://www.allthingsdistributed.com/2019/08/modern-applicat...)

Re: Serverless: slower and more expensive

#509

I did the same experiment as OP and ran into the same issues, but eventually realized that I was "doing serverless" wrong. "Serverless" is not a replacement for cloud VMs/containers. Migrating your Rails/Express/Flask/.Net/whatever stack over to Lambda/API Gateway is not going to improve performance or costs. You really have to architect your app from the ground-up for serverless by designing single-responsibility mi…

Firebase now makes most of these painless. They've done a really good job. If your starting from the grounds up and can stomach using a google product Firebase is the easiest to work with by far.

Do you have some more to read about that? Sounds interesting but I'm now confused as to what FireBase is/does.
Post reply on HN