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

581–590 of 733 posts

Re: Serverless: slower and more expensive

#581

Post by staticassertion »

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 only valid options for performance sensitive functions are JS, Python and Go.

With custom runtimes that's not the case anymore. I write my lambdas in Rust.

Can't stress (7) enough, would also add 'morale' savings. It can be really stressful for developers to deal with gratuitous ops work.

Re: Serverless: slower and more expensive

#582

Post by quickthrower2 »

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.

The use case is lumpy work. You have some batch processes that are unpredictable. Could be hours without a call, then suddenly you need to scale up to 20 cpu to process a bunch of requests. One example is say processing pdfs in a crud app where people can generate pdfs on demand with large images.

I have used Azure Functions so I will talk to that: There are two options, one is a consumption plan where it is truly 'serverless' and they provide you with server time on demand. The other plan - app service plan - allows you to run these on your existing Azure resources. Another option is to get the runtime on a Docker image and run it on a container outside of Azure completely (but you lose a lot of the monitoring benefits).

Anyway the point is that at least in Azure you can sort of slide the dial to how 'serverless' you want to be - one extreme is the consumption plan, then you can go with the app service plan, then less serverless would be to run AKS (Kubernetes) with autoscaling, then to run VM's with autoscaling, then VM's with manual scaling, then finally perhaps rent a physical server in a data centre, then buy a physical server and stick it in a rack in your office.

The advantage of pure serverless over the less extreme ways is if you have wildly unpredictable loads going from 0 to high to 0 at different times, and don't want to (or can't) set up a reasonable scaling system to suit (or don't want to wait for the scaling to 'kick in').

Re: Serverless: slower and more expensive

#583

Post by nailer »

LunaSea wrote: post #411
nailer wrote: post #373

Earlier quoted context omitted.

> > > my dependencies might be different > > No, the lockfile does that. > your lockfile doesn't care about build steps Then you're not talking about dependency versioning are you? you're talking about install order. In practice it hasn't been an issue, I should find out how deterministic install order is but I'd only be doing this to win a silly argument rather than anything that has come up in nearly a decade of ma…

> Then you're not talking about versioning are you? you're talking about install order. I didn't mean build order but install scripts and native module builds. The first type can create issues when external resources are downloaded (Puppeteer, Ngrok, etc.), which themselves have different versions or that fail to download and where the Node.js module falls back to another solution that behaves slightly differently. T…

> > > my dependencies might be different

...

> I didn't mean build order but install scripts and native module builds.

OK. Then you're still not talking about your dependencies being different. The dependencies are the same, they're just particular modules with very specific behaviour...

> external resources are downloaded (Puppeteer, Ngrok, etc.), which themselves have different versions or that fail to download

That's more a 'heads up when using puppeteer' than a indictment of serverless and a call to add an environment management layer like we did in 2005-2015.

> Linux by default uses XFS on EBS disks so I wouldn't be surprised if Lambda's used the same.

That's worth checking out.

> Debugging which starts by finding exactly the differences between the two environments which would have been solved by a VM or Docker.

I see what you're saying, but planning your whole env around something like a given puppeteer module dynamically downloading Chrome (which is very uncommon behaviour) isn't worth the added complexity.

Re: Serverless: slower and more expensive

#584

Post by Scuds »

thramp wrote: post #456
zeawee wrote: post #102

Earlier quoted context omitted.

Because Rust doesn't have a runtime initialization.

Rust AWS Lambda Runtime author here: while the Rust runtime tends to beat all other runtimes, Go is _very_ close in terms of startup times.

this? https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws...

https://github.com/awslabs/aws-lambda-rust-runtime

https://crates.io/crates/lambda_runtime

you rock! That docker based build system makes building those MUSL based rust binaries a snap!

Re: Serverless: slower and more expensive

#585

Post by kurige »

munns wrote: post #445
kurige wrote: post #440

Earlier quoted context omitted.

Maybe that's how he got the job.

No. I've been at AWS for over 7 years in a few different roles. Came to the serverless space >2.5 years ago because I felt passionate about it (could have literally done almost anything). Again, sorry for mis-posting under my older personal account, it was rarely used fwiw.

I wasn't criticizing you. I was pointing out that an equally likely and more charitable interpretation is that you posted as a fan of AWS before you started posting as an employee.

Turns out I was wrong in this case, but you've explained the situation and everything is hunky dory.

Re: Serverless: slower and more expensive

#586

Post by jjeaff »

johnfactorial wrote: post #286
rdsubhas wrote: post #114

This is how a conversation with a colleague who were enthusiastic about Serverless, and who's company was mostly on Java/JVM stack went: Colleague: Lambda is awesome, we can scale down to zero and lower costs! We love it! We use cool tech!! Me: What did you do about JVM warm up? Colleague: We solved it by having a keepalive daemon which pings the service to keep it always warmed up. ... Me thinking: Uhh, but what abo…

> Lambda seems to be a fast prototyping tool. My thoughts EXACTLY. The great power in "serverless" architecture (i.e. AWS Lambda + AWS RDS + AWS Gateway) is how it empowers prototyping a new product. Counterintuitively, it's future-proofing. You should know in advance that it's too slow & expensive. But you get to spin up a prototype backend very rapidly, pay only for what you're using while prototyping, and Lambda's…

For me, the absolute best use cases for serverless is for really infrequent, small tasks.

For example, I have a few data scrapers written in JavaScript but my regular stack is lamp.

So I don't have any need to run a node server 24x7 just for those once a day tasks.

But I have even found myself not needing serverless for that because everything is running in a kubernetes cluster. So I can just setup a cron to run them which launches the needed node containers.

So I guess in effect, I am just using a sort of self-managed "serverless".

Re: Serverless: slower and more expensive

#587

Post by ClumsyPilot »

chrshawkes wrote: post #410
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…

GraphQL makes caching a real bitch.

It might do, bu let for some APIs caching doesn't even make sense.

Re: Serverless: slower and more expensive

#588

Post by ClumsyPilot »

0xbadcafebee wrote: post #330
claudiusd wrote: post #311

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…

> You really have to architect your app from the ground-up for serverless by designing single-responsibility microservices that run in separate lambdas, building a heavy javascript front-end in your favorite framework (React/Ember/Amber/etc), and taking advantage of every service you can (Cognito, AppSync, S3, Cloudfront, API Gateway, etc) to eliminate the need for a web framework. At least I don't have to learn that…

I am similarly, reading this list and wondering

Re: Serverless: slower and more expensive

#589

Post by TheCoelacanth »

scarface74 wrote: post #472
TheCoelacanth wrote: post #454

Earlier quoted context omitted.

And bare-metal servers can do everything Fargate can without limitations. The point of both is to sacrifice some capabilities in order to remove operational complexity. Lambda just goes farther along that spectrum than Fargate does.

How so? With lambda you give AWS a zip file with your code in it and with Fargate you give AWS a Docker Container. The only difference is that AWS doesn’t support the event triggers with Fargate out of the box.

A docker container is not just your code. It's basically the entire userspace portion of an OS plus your code.

Re: Serverless: slower and more expensive

#590

Post by ClumsyPilot »

nailer wrote: post #321
LunaSea wrote: post #159

Earlier quoted context omitted.

It's great to see that factual evidence is answered with ad-hominem by the Lambda hype crowd. In any case, if you have a Node.js module or code with a native C/C++ build, that runs shell commands, that writes to disk (not allowed besides /tmp in Lambda) or makes assumptions about the OS, your "simple" function will absolutely return different results. e.g: My lambda is called when somebody uploads an image and return…

> > Writing a function in node 12 and then running it on node 4 and throwing your hands in the air cos it didn’t work isn’t the fault of Lambda. > It's great to see that factual evidence is answered with ad-hominem by the Lambda hype crowd. I don't think that was a personal attack. We've answered technical questions with technical answers. - You have a definition of stateless which includes having no persistence laye…

The place where I work, we have "cloud in a cloud" initiative, total waste of time But you can't blame containers for it
Post reply on HN