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

491–500 of 733 posts

Re: Serverless: slower and more expensive

#491

Post by Pxtl »

radicalbyte wrote: post #78
laumars wrote: post #72

It's not as clear cut as the article describes though. For low usage stuff serverless is cheaper. For "spiky" traffic - particularly when those spikes are unpredictable - serverless is often cheaper and sometimes faster too (eg if your spikes ramp up quicker than the spin up times of virtual machines). Also AOT compiled languages like C# will run slower on lambda than pre-compiled on an EC2. You shouldn't need benchm…

C# is compiled to an intermediate language (MSIL/CIL^) which is then JIT-ed. The JIT cost actually adds a fair bit to the start-up time for C# code. This is why on the webserver there's an option to keep the C# code resident so it's always ready to go. In the past - before this option - it was common have scheduled jobs which pinged your webapp regularly to keep it hot :) ^ https://en.wikipedia.org/wiki/Common_Interm…

This to me smells like "things I shouldn't have to care about when using a serverless architecture". I would expect the serverless provider to keep my code fully AOT compiled in the fastest cold-start-format instead (wasn't ".net native" a thing?) of JITing things at the last second.

Re: Serverless: slower and more expensive

#492

Post by scarface74 »

mywittyname wrote: post #482
scarface74 wrote: post #386

Earlier quoted context omitted.

There is no reason that Fargate can not be a replacement for lambda. There are three use cases for lambda: 1. Event based triggers where something happens externally that you want to process. You can do the same thing with Fargate by either having a continuously running process that reads from a queue or responds to an API request (AWS Event -> SNS -> API). 2. Timed events. You can do this with Fargate directly ( htt…

Fargate is slow to spin up and can only run 50 simultaneous instances. But they can run "forever" and have much higher memory constraints. Lambdas relatively fast to spin up and thousands instances can be run at once. But they are time limited running for at most 5 minutes and using 3GB of RAM. You can do most of the same things with either (after all, they just execute code), but you cannot ignore their very differe…

The limit of 50 is a soft limit - you can send a support request to get it raised and they usually respond within a half an hour. Lambda also has a default soft limit of 2000.

But, also you can have up to 4 vCPUs with Fargate as opposed to one with lambda.

Re: Serverless: slower and more expensive

#493

Post by smacktoward »

mytailorisrich wrote: post #415
lallysingh wrote: post #414

Earlier quoted context omitted.

It's almost never about server capacity. It's usually about who's maintaining them, who controls the updates and versions of software on there, and which dept the server's billed to. All stuff that's reasonable for things of a certain size, but unreasonable for things too small or big to fit the process will.

Ah so it's serverless as a tool to work around corporate red tape, then ;)

I would love to see a study of how much IT spending in general is just for tools to work around corporate bureaucracy. I suspect the figure would be staggering.

Re: Serverless: slower and more expensive

#494

Post by [deleted] »

tus88 wrote: post #164
cryptica wrote: post #17

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

#495

Post by ErikAugust »

cryptica wrote: post #17

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…

You know what I actually like Serverless (AWS Lambda) for?

Adding a script that is triggered upon a new message to an SQS queue. The cost in using AWS Lambda is actually in the use of API Gateway, and it doesn't use that, as well.

Now, you're right, I didn't find this from any thought leaders, etc. In fact, I would disregard anyone who couldn't give me a concrete use-case and a cost/benefit overview for a technology. I have met a few executives that more or less were trojan horse leaders for other companies' technologies. Salesforce rings a bell.

Re: Serverless: slower and more expensive

#496

Post by [deleted] »

mytailorisrich wrote: post #415
lallysingh wrote: post #414

Earlier quoted context omitted.

It's almost never about server capacity. It's usually about who's maintaining them, who controls the updates and versions of software on there, and which dept the server's billed to. All stuff that's reasonable for things of a certain size, but unreasonable for things too small or big to fit the process will.

Ah so it's serverless as a tool to work around corporate red tape, then ;)

[deleted]

Re: Serverless: slower and more expensive

#497

Post by wolco »

lucasverra wrote: post #15
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…

Agreed, let me add my 2cts : >The whole idea of serverless is so you don't have to manage infrastructure. ...when you are validating your product/market (100 request/day is a success here). Not everyone on HN is a core dev, tech is getting democratised. So 1 week of time dealing with servers and accounts and infra is a week not asking the right questions.

Learning how to setup everything will be too much for you. Use Hostgator and you can start marketing immediately.

Re: Serverless: slower and more expensive

#498

Post by redisman »

dullgiulio wrote: post #150
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,…

Just to be clear: lambdas are not stateless if you, for example, connect to a DB or use any other external service. State could be somewhere else, but if you are not also "pure", you don't have any improvement over a normal service.

Lazy initialization and caching of a resource literally every instance of a Lambda uses doesn't fit the definition of "state" in my opinion.

Re: Serverless: slower and more expensive

#499

Post by danenania »

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…

"It's also great for when you're first starting out and don't know when or where you'll need to scale."

To me this is probably the most significant benefit, and one that many folks in this discussion strangely seem to be ignoring.

If you launch a startup and it has some success, it's likely you'll run into scaling problems. This is a big, stressful distraction and a serious threat to your customers' confidence when reliability and uptime suffer. Avoiding all that so you can focus on your product and your business is worth paying a premium for.

Infrastructure costs aren't going to bankrupt you as a startup, but infrastructure that keeps falling over, requires constant fiddling, slows you down, and stresses you out just when you're starting to claw your way to early traction very well might.

Re: Serverless: slower and more expensive

#500

Post by dkarras »

blantonl wrote: post #302
jrochkind1 wrote: post #191

While there is a lot of lambda/serverless hate in this thread, I (who have no experience with it) am reluctant to conclude based on this alone that lambda is useless/stupid. Need more info. Is there anyone who has had success using lambda, or can anyone find a write-up of a success story? That would help me (and others) understand/believe better I think; if it's a very rare case where lambda ends up being helpful (wh…

For my organization, Lambda has been instrumental in allowing us to take some highly trafficked, small API services, and migrate them from NodeJS based servers that we manage to Lambda and Application Load Balancer that just works with no involvement. We're not relying on the API gateway (which is expensive and better suited for non-public APIs). Many of these APIs are Ajax type status updates, JWT issuers, authentic…

How did the cost profile change? You can include reduced labor costs if you want.
Post reply on HN