Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

211–220 of 733 posts

Re: Serverless: slower and more expensive

#211

Earlier quoted context omitted.

So possibly a good fit for IoT.

No. It depends on the IoT application. The one I'm involved with (smart metering) produces data at regular 15 minute periods 24/7. This is a very predictable and constant traffic load and not at all suitable for serverless/lambda. In fact, its the complete opposite. Many IoT applications are very predictable (anything with regular sensor-readings for example or with repeatable patterns such as people returning from w…

What you need to consider [is] that there are a lot of applications like yours hosted by an IoT SaaS. (I work on one.)

So the patterns are (obviously) predictable, but the 'dynamic range' of the load is extremely wide, ranging from stampedes on the cardinal points of the clock face (0/15/30/45 min) to crickets the rest of the time. Some form of elasticity is required unless you are willing to pay for idle servers sized for the episodic peaks.

Re: Serverless: slower and more expensive

#212
Thank you for writing this! It’s always interesting to see how other people set up their stacks.

Recently, I created some twitter bots to test out for fun and put them on Lambda with a 12 hr schedule to run from SNS... I was sending 15 tweets a day (from ~15 accounts) and my bill was $35/mth... That is silly

Re: Serverless: slower and more expensive

#213
The pricing he quotes in the article he quotes 1350$ per month. If you remove API gateway (which appears you can) , price is about 300$ (from the article itself).

He never mentions what memory provisioning he uses for his lambda but he does remarks that he has 10M requests a day and that'll cost 10$ a day in lambda costs. Which comes to 0.000001 per request. That puts his service at 512MB memory at 0.000000834 (+ 0.0000002 per request).

If instead he used a 128MB instance (which is reasonable if your request is 3ms, but probably not enough to run .net core) you'll be at ~0.0000004 . Which would put it at roughly half cost. At about ~120$, which is the same as his server setup.

He did mention that he could cut his costs by reducing memory usage.

Seems like there's no reason why it couldn't match up to the server-side cost. I don't think the cost-benefit analysis is as bad as he makes it out to be.

Seems also like there's a very big mismatch in pricing here. If his workload is about 3ms per request but he is charged for 100ms a request, then that's a 33 fold increase in pricing compared to being charge per millisecond. Seems like quite an opportunity for some cloud provider to differentiate itself.

Re: Serverless: slower and more expensive

#214
Related: Hellerstein et. al's paper evaluating the limitations of serverless frameworks for different use cases. (https://blog.acolyer.org/2019/01/14/serverless-computing-one...)

tl;dr FaaS lifetimes, lack of cache locality, network rates and isolation make serverless platforms great only for embarassingly parallel, short-lived, I/O-bound tasks that don't require high performance and are only occasionally run. Anything else will be more expensive and slower than just maintaining your own server.

Lambda thus would be perfect for irregular batch jobs or orchestration tasks. Trying to serve an API isn't advisable because of the low-latency requirements.

On a tangential note, AWS Lambda is actually insufficient to serve an API by itself - you also need to use AWS API Gateway to serve incoming requests, create your own route tables and dedicated subnets if you need to allow VPC access, enable Cloudtrail logging and monitoring (very limited), and add IAM rules to allow all of these to interoperate. It is not a turn-key solution by any means.

Add to this the limits on deployment artifacts (50 MB max), and you've basically done all the work needed to launch your own EC2 instance in its own subnet and availability zone, but resulting in something with smaller capacity and worse observability.

Use a server, dammit.

Re: Serverless: slower and more expensive

#215

It's concerning how typical the hype machine is in IT. I believe Serverless has its place and value. So does Kubernetes or many other products that are often discussed on HN. But let's be clear, we are talking about commercial products and there is a capital interest in selling these services to all of us devs and engineers. So while use cases exists and benefits wait to be reaped, as a consultant I strongly feel tha…

> It's concerning how typical the hype machine is in IT. Software engineering is still a young discipline. Probably half of the people have less than 4 years of experience. They learned from other employees that also had less than 4 years of experience. And that can be repeated for 10 generations of developers. We are learning, and re-learning the same lessons again and again. Everything seems new and better and then…

> Everything seems new and better and then we are surprised when it's not a silver bullet.

We need to live and breathe a culture that makes even young developers aware that this mistake has been done over and over until a growing collective of developers has recognized the pattern behind this.

After all, in the analogue trades even apprentices are taught many "don'ts" right from day one. Software engineering should not be any different.

Re: Serverless: slower and more expensive

#216

It's concerning how typical the hype machine is in IT. I believe Serverless has its place and value. So does Kubernetes or many other products that are often discussed on HN. But let's be clear, we are talking about commercial products and there is a capital interest in selling these services to all of us devs and engineers. So while use cases exists and benefits wait to be reaped, as a consultant I strongly feel tha…

> correct me if wrong Stack Overflow is built on ASP.NET: https://stackoverflow.blog/2008/09/21/what-was-stack-overflo...

Thank you!

Re: Serverless: slower and more expensive

#217
"Serverless" is basically yet another manifestation of the fact that (despite recent controversy about, well, him being weird) Stallman was right about open-source. The alternative to serverless - open-source products like Mesos, DCOS, Nomad, etc. - offer the same functionality to engineering organizations at lower cost with vastly more pleasant (and manageable) support for things like CI. It's been a great money-making scam for the "cloud" companies though. "Serverless" is closed-source by nature, and it will never be as efficient as open-source solutions.

Re: Serverless: slower and more expensive

#218

Earlier quoted context omitted.

So possibly a good fit for IoT.

No. It depends on the IoT application. The one I'm involved with (smart metering) produces data at regular 15 minute periods 24/7. This is a very predictable and constant traffic load and not at all suitable for serverless/lambda. In fact, its the complete opposite. Many IoT applications are very predictable (anything with regular sensor-readings for example or with repeatable patterns such as people returning from w…

People 'returning from work' and 'turning things on' are exactly the kind of situation where serverless/lambda shines.

See also: traffic jams and people switching on their electric kettles en-masse during intermission of major soccer matches. The first disrupts whole economies and the second has given rise to 'fast pumped storage' at the electrical grid level.

Just because you don't see the accumulated effects does not mean they aren't there.

Re: Serverless: slower and more expensive

#219

I recently saved a company from serverless: development had completely stalled, continuous delivery was insanely inefficient (you couldn't deploy your set of functions at once because of dependencies), vendor lock-in made it a pain to develop locally (cognito in particular), CI testing was also a big pain (serverless-offline), the project also had reached the endpoint limit so basically they had to split the project…

Sometimes the right solution is just the easiest. Most of the time just is. Congrats.

Re: Serverless: slower and more expensive

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

I really doubt not managing servers is an advantage other than initial launch for MVP or some simple webhook. The overhead of managing API gateway, monitoring and log in a more large scale serverless application is larger than managing several linux servers.
Post reply on HN