Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

351–360 of 733 posts

Re: Serverless: slower and more expensive

#351
post #335
post #249

Earlier quoted context omitted.

True. I stopped using windows for dev machines long time ago, but I'd guess with the Linux subsystem stuff it will catch-up in the next years.

I honestly have no problems developing on windows (except when my macos coworkers dont consider windows). Docker is the only real issue.

Yes, it's unusable on macos and windows.

Hopefully WSL2 will solve this.

Re: Serverless: slower and more expensive

#353
post #69

Earlier quoted context omitted.

> We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) That goes without saying! That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before. I don't think anybody uses things like AWS or serveless…

If we really want easy, we’d all be writing ColdFusion or Visual Basic.

If we valued productivity, and those were indeed easier, then we should.

There's no real pride in not valuing easy if it's also good.

Re: Serverless: slower and more expensive

#354

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…

To eliminate the need of a web framework? I don’t understand the rationale, if I can get all what’s mentioned done with a good web framework, I will be more than happy to do that.

Re: Serverless: slower and more expensive

#355

Earlier quoted context omitted.

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.

Low latency for 1m requests in one second? Yeah, Lambda won’t help you with that. Their cold starts will stop you dead. Particularly if you’re in a VPC and they have to allocate servers with the appropriate ENI. Not to mention, you’ll be hitting concurrency limits. Sure, if you ping your lambdas frequently to keep them from having cold starts, and you’ve worked with Amazon to increase your concurrency limits 100 fold…

Cold starts for node are ~500ms.

Re: Serverless: slower and more expensive

#357

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

I looked at his site and he's pushing game state over websockets. I think he could eliminate almost all of his back end calls to his servers besides game initialization by using DynamoDB directly via Cognito, though the logic for proposing a move from one user and having it accepted in the game state by another user becomes an interesting problem.

Re: Serverless: slower and more expensive

#358

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

To me, serverless promises "no hassles" hosting. If what I save on sysadmin stuff needs to be replaced with a lot of new accounting stuff, where's the saving?

Re: Serverless: slower and more expensive

#359
post #298

Earlier quoted context omitted.

> Node.js version might be different Yes, in major only. Your lambda has node 10, you might be running 10.x or 10.y > my dependencies might be different No, the lockfile does that. > the OS is different, the filesystem is different Agree, but how much does one Linux+systemd different from other Linux+systemd? How much does the FS? > It's the reason people started using Docker really. VMs, docker and having to care ab…

> No, the lockfile does that. No, your lockfile doesn't care about build steps so any post-install script might run differently for the many other reasons listed. > Agree, but how much does one Linux+systemd different from other Linux+systemd? How much does the FS? Plenty. For example filesystem change events are known to have filesystem and OS dependent behaviours and quirks / bugs. When a Node module runs a shell c…

> No, your lockfile doesn't care about build steps so any post-install script might run differently for the many other reasons listed.

You shouldn’t be uploading node_modules folder to your deployed lambda so this is an issue of your development environment, not lambda.

> Maybe, but serverless doesn't answer those questions at all.

“Serverless” or lambda/Azure functions, etc, are not a silver bullet that solve every single scenario. Just like docker doesn’t solve every single scenario, not does cloud servers or bare metal. It’s just another tool for us to do our job.

Re: Serverless: slower and more expensive

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

Serverless works great for my apps. My traffic is driven by hourly notifications so I get 100x more traffic on the hour than the rest of the hour. I could write a bunch of ML to figure out load scaling but that is code I don't want to focus on.
Post reply on HN