Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

531–540 of 733 posts

Re: Serverless: slower and more expensive

#531
I'm personally not a big fan of "serverless", but I think this article is a bit unfair.

First off, API Gateway might not have been the best choice here; an ALB would probably do the trick for this use case and be cheaper. Debatable if it's fair to include API Gateway in the cost anyway; Lambda is really the "serverless" bit here, but I guess Lambda by itself isn't all that useful if you have no way of invoking it.

Beyond that, they're pushing "slower and more expensive" as a sort of indictment of serverless, that it's worthless. It's a trade off. You're trading price and performance for someone else managing the infrastructure for you. For some people that might be a reasonable trade off, and for others it might not.

Put another way: serverless is more expensive than EC2 -> EC2 is more expensive than a dedicated server -> a dedicated server is more expensive than buying your own and racking it -> etc.

Well, yeah, that's only all true if you only consider the narrow band of cost that you've cherry-picked to be relevant. Obviously buying your own server and racking it has other costs than just the server and the colo space, managing an EC2 instance costs more than just the per-hour rate AWS charges, and so on.

Re: Serverless: slower and more expensive

#532
post #422

Earlier quoted context omitted.

>HN is usually a pretty good gauge for how the wider engineering community feels about a particular technology. HN is a pretty good gauge for how a subset of a very startup focused portion of the engineering community feels about technology. I don't know that the same can be said about it reflecting the opinions of the engineering community on the whole, or if the community is even unified enough for anything to be a…

This! There are lots of people in tech that don’t know/visit HN !

I honestly doubt that anyone else in my team of 7 reads HN. There's one guy who might. The rest, it just doesn't seem in their character.

While we might like to think the opposite, I feel like the majority of people in our profession are like the majority of people anywhere -- going to work to work, and going on FB/twitter/reddit to waste time. I don't know many devs personally who take a big interest in the goings-on of the startup world or open-source world in the large. Do they care about spending some of their free time honing their craft or messing around with a new tool? Absolutely. But few seem like the type who would enjoy engaging in a quasi-philosophical discussion on the strengths of various design paradigms. They spend all their day thinking at work; not many want to continue thinking about the same sort of stuff during their off hours.

Re: Serverless: slower and more expensive

#533
post #457

Earlier quoted context omitted.

You're using Lambda because you haven't figured out how to enable cgi-bin in Nginx?

How can cgi-bin in Nginx help in his case?

Narrator: It can’t.

Well, it can, but that’s the trivial part of all this. Tweaking a web server config is like 1% of the problem.

Re: Serverless: slower and more expensive

#534
post #511

Earlier quoted context omitted.

Really? Hahahha

Miles and I know each other, what's wrong with a friendly hug? Do you need a hug hesburg?

I recall a certain uptight code of conduct which explicitly forbids unasked for virtual hugs.

Re: Serverless: slower and more expensive

#535

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 ;)

A market that will never die!

Re: Serverless: slower and more expensive

#536

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.

Burst traffic with high writes? --> Use a stream. Burst traffic with high reads? --> Use a cache. Large compute and memory intense stuff isn't suitable for serverless

What kind of stream do you have in mind? I don’t follow.

Re: Serverless: slower and more expensive

#537
Any of the IaaS, PaaS, SaaS, "serverless" (I'd slide that into the SaaS category) computing is just differing levels of out sourcing. Did you expect a managed service provider to be faster? Look after the stack yourself to avoid someone else's junk on your monthly rented computer.

Re: Serverless: slower and more expensive

#538
post #164

Earlier quoted context omitted.

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.

> For the 80% or more, serverless works just fine. Cite this. I don't believe you. I'm across a pretty broad slice of industry and can only draw on anecdotes from colleagues, but the majority of people with actual hands-on experience are disillusioned and say that the biggest (only?) drive for serverless at this point is top-down organisational pressure created by technically incompetent strategic management that loo…

FWIW. It has worked great for us, saving us mid six figures per year or more. The savings keeps increasing as we figure out ways to move more of our workload over to Lambda, we are even running PHP there. Step functions, lambda, sns, sqs and api gateway are pretty cool tools for a lot of projects when used properly. I think the paradigm shift in how you need to make things work is frustrating for some, but once you get it, it works nicely.

I have also helped engineers at two other companies start making the switch and they are both happy so far... so, in my (obviously limited) first hand experience it works 100% of the time. :)

Re: Serverless: slower and more expensive

#539
post #393

Earlier quoted context omitted.

Lambda is 5 year old technology. This is like arguing in 2011 that startups shouldn’t use EC2, because it’s “risky”.

The technology age isn’t the issue. The issue is how many projects have successfully deployed large scale reliable systems built with Lambda.

The internet is full of success stories if you care to look. My favorites:

- iRobot (maker of Roomba) has been running its entire IoT stack serverless since 2016 (architect Ben Kehoe is a worthwhile follow on Twitter)

- Reddit’s video hosting service is built and operated by a single engineer on a serverless stack

Re: Serverless: slower and more expensive

#540
post #355

Earlier quoted context omitted.

Cold starts for node are ~500ms.

Add a couple of seconds when spinning up an ENI. New nodes in a VPC are around 3 seconds (and our last EBC with Amazon indicated that it won't get lower than that for awhile). It's worth noting that this impacts ECU scaling for Aurora Serverless as well. Why would you need to put a Lambda in a VPC? For access to a database, other EC2 bound resources, or overall network security reasons (such as outbound network monit…

You may be interested in the latest news re: allocating ENIs in VPCs for Lambda[1]. They've finally got the cold-start situation a little more under control in that scenario.

Here's the meat, to save you a click:

> AWS says that the one-time setup of the shared network interface can take 90 seconds to complete. But because the network interface gets created when Lambda functions are first created or VPC settings updated, the connectivity-related latency during cold start approaches zero. The same goes for function scaling, which no longer requires new network interfaces for each new execution environment.

[1]: https://www.infoq.com/news/2019/09/aws-lambda-vpc/

Post reply on HN