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

121–130 of 733 posts

Re: Serverless: slower and more expensive

#121

Post by nailer »

LunaSea wrote: post #118
nailer wrote: post #89

Earlier quoted context omitted.

> Testability? Serverless is specifically a stateless paradigm, making testing easier than persistent paradigms. > Framework adoption? Generally we use our own frameworks - I do wish people knew there was more than serverless.com. AWS throw up https://arc.codes at re:Invent, which is what I'm using and I generally like it. > Stability? Industry Skills? Proven Architectures...? These are all excellent questions. GAE,…

> Serverless is specifically a stateless paradigm, making testing easier than persistent paradigms. No because Lambdas are proprietary which means you can't run it in a CI or locally. Also, it becomes stateful if it pulls data from a database, S3 or anywhere else on AWS which it almost always does. > Serverless isn't much younger than say, node.js and Rust are. AWS Lambdas which I consider to be the first widely used…

> No because Lambdas are proprietary which means you can't run it in a CI or locally.

Arc has a full sandbox, so yes you can run a lambda in a CI or locally. You should know this - if you're developing your apps by deploying every lambda as you edit it you're doing it wrong. Most lambdas don't really need you to simulate AWS.

> Also, it becomes stateful if it pulls data from a database, S3 or anywhere else on AWS which it almost always does.

Sure, persistence exists, but when people say 'stateless' they mean 'has no transient state'. They don't mean 'has no data'.

> AWS Lambdas which I consider to be the first widely used Lambda service

OK. You don't consider GAE (2008) widely used. I disagree - mainly because I was using GAE back then and thinking about this new world of no-memory, timeouts, etc - but lambda is definitely more popular.

Re: Serverless: slower and more expensive

#122

Post by jacquesm »

I've seen a few good applications for 'serverless' and a whole raft of bad ones. Yes, the tech has its upsides if you have a few million devices in the field and they can randomly start reporting. But for most applications it is overkill and some forethought might save you having to deal with that particular problem in the first place. Forethought: randomize your connect moments and exponential back-off in case you can't connect.

Re: Serverless: slower and more expensive

#123

Post by jacquesm »

cuu508 wrote: post #39
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.

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.

But if your hosting costs are a round-off on your budget that might not be an issue.

Re: Serverless: slower and more expensive

#124

Post by jacquesm »

eternalban wrote: post #106
ShinTakuya wrote: post #80

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.

So possibly a good fit for IoT.

Yes.

Re: Serverless: slower and more expensive

#125

Post by scarface74 »

aserafini wrote: post #36
jedberg wrote: post #5

They're doing over 100rps if they're doing 10M requests a day. That's not a good use case for Lambda. If you're going to be that heavily utilized it makes more sense to run your API on EC2 or ECS/Fargate/etc. Lambda is a good use case for when you have lots of not-often-used APIs. Lambda is a great solution for an API that's called a few times a day. It's also great for when you're first starting out and don't know w…

I think the problem is that moving from Lambda/FaaS to a container-centric alternative (ECS and friends) requires a complete re-architect of your stack. Whereas starting with a simple, single container solution and organically evolving that into container-orchestration is much simpler - because the fundamental building block hasn't changed. It's all just containers. Personally I'd like to see the industry coalesce on…

I think the problem is that moving from Lambda/FaaS to a container-centric alternative (ECS and friends) requires a complete re-architect of your stack.

Not really. I converted a Node/Express API running in lambda using the proxy integration to a Docker/Fargate implementation in less than a couple of hours by following a Fargate tutorial. Most of that time was spent learning enough Docker to do it.

The only difference between the Docker implementation of the API and the lambda implementation was calling a different startup module.

There is nothing magical about any lambda, from the programming standpoint you just add one function that accepts a JSON request and a lambda context.

Converting it to a standalone service (outside of APIs) is usual a matter of wrapping your lambda in something that runs all of the time and routing whatever event you’re using to trigger to a queue.

Re: Serverless: slower and more expensive

#126

Post by philliphaydon »

LunaSea wrote: post #118
nailer wrote: post #89

Earlier quoted context omitted.

> Testability? Serverless is specifically a stateless paradigm, making testing easier than persistent paradigms. > Framework adoption? Generally we use our own frameworks - I do wish people knew there was more than serverless.com. AWS throw up https://arc.codes at re:Invent, which is what I'm using and I generally like it. > Stability? Industry Skills? Proven Architectures...? These are all excellent questions. GAE,…

> Serverless is specifically a stateless paradigm, making testing easier than persistent paradigms. No because Lambdas are proprietary which means you can't run it in a CI or locally. Also, it becomes stateful if it pulls data from a database, S3 or anywhere else on AWS which it almost always does. > Serverless isn't much younger than say, node.js and Rust are. AWS Lambdas which I consider to be the first widely used…

> No because Lambdas are proprietary which means you can't run it in a CI or locally. Also, it becomes stateful if it pulls data from a database, S3 or anywhere else on AWS which it almost always does.

Lambda is a function call. So it makes no difference if it’s proprietary or not.

Are you saying that it’s difficult to test passing an object to a function and asserting that it’s functioning as intended?

Re: Serverless: slower and more expensive

#127

Post by peterwwillis »

coldtea wrote: post #73
peterwwillis wrote: post #56

Earlier quoted context omitted.

> The whole idea of serverless is so you don't have to manage infrastructure. OS patching, mucking around with Docker and and port fowarding rules are all removed once you go down the serverless route. If this were the reason to use Serverless, it doesn't buy you much. Ports? You set that up once and you're done forever. OS patching? You already have to manage patches for your app and its libraries, so OS (really con…

> If this were the reason to use Serverless, it doesn't buy you much. Ports? You set that up once and you're done forever. OS patching? You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy. This is "you'll always have to do X, so might as well do 10x" argument...

Who would argue that? Why would you ever want to do 10 times something just because you do it once?

Re: Serverless: slower and more expensive

#128

Post by laumars »

scarface74 wrote: post #111
laumars wrote: post #95

Earlier quoted context omitted.

I'm getting heavily downvoted for the C# point when benchmarks do demonstrate that C# does have a measurably slower cold start time than many other language runtimes; in fact slower than every JIT language. So I'm not actually wrong on that point. > But that is what the author did. C# is not 'fully' AOT, it is JITed into MSIL on .net CLR, at least under normal circumstances. Does elastic beanstalk use .net native sty…

This is no secret. C# and Java are slower with lambda than scripting languages like Python and Javascript. Whether it’s slower overall, I haven’t seen benchmarks and outside of lambda, the startup time cost is usually negligible.

Slower overall very much depends on your workload and the way the code is written. However lambda is supposed to be short lived processes and AWS manage the concurrency so the actual performance difference of each language is mitigated somewhat for the average customer (edge cases will always exist).

It's also worth noting that if you're running the kind of processes that this does become a concern, then lambda is probably the wrong choice anyway. However, as always, the smart thing to do is build then benchmark (as the author did).

Re: Serverless: slower and more expensive

#129

Post by skrebbel »

tedk-42 wrote: 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…

> I'm in the container camp

Can anyone explain to me why there's "camps" to this debate?

Re: Serverless: slower and more expensive

#130

Post by scarface74 »

gigatexal wrote: post #42

I thought commenter W. Van Dam made some good points: “ First, you don't need API Gateways if you use an AWS SDK. Like this guide shows. And of course you don't need a load balancer, because that's precisely one of the things that serverless takes care of for you :-) More importantly, you didn't actually compare serverless to your current situation. With serverless solutions you can typically save cost in terms of se…

You can do the same thing with Lambda @ Edge and CloudFront for .60 per million requests and there is a free tier. (https://aws.amazon.com/lambda/pricing/)
Post reply on HN