Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

461–470 of 733 posts

Re: Serverless: slower and more expensive

#461
One question, which is puzzling me:

- there is a company which provides you with IT administration, which you trust it cpu management, memory management, network management,...

- in most cases (not all, but in most cases), you are developers not system administrators

- you dont have resources in term of hardware budget (in form of multi year plan), network budget, human resources budget, own knowlidge budget,... to set it up as a single man / company operation

Why do you believe, that some company that offers you all those "favors" would make it cheaper than if you wouldnt lack those topics? Even more as there is a huge mountain of knowlidge/time/money/... you dont have?

If I were them, I would spoil everybody to the point where developers wouldnt know what ip is, run operation on my own expenses and then raise up the prices a lot. And I dont think I am much smarter then "them".

To me it is dead simple. Same as all the cloud topics. It is a reasonable trade off, the companies are offering you a "favor" for money in same way that you do it customers.

Re: Serverless: slower and more expensive

#463
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…

Datapoint:

I'm using serverless because it lets me deploy a new API endpoint in a matter of minutes.

There is 0 configuration, and deployment is a single command. I also have my own servers running some of my APIs, the difference how much work I have to do is huge. Serverless on Google Firebase is literally "export a function, now you have a new endpoint!".

There is, quite literally, nothing else to do.

I can move 5x-10x the speed with serverless. There is less (almost 0) infrastructure to maintain.

Yes, it costs more, although the math with Google Firebase Functions is pretty trivial, everything is bundled under 1 service, and sending data around between Google cloud services is free.

Re: Serverless: slower and more expensive

#464

Earlier quoted context omitted.

It’s rare for things to go so disastrously wrong that legal sway is relevant. What’s much more common is an angry CTO looking for someone to be mad at, and Amazon doesn’t have any particular ability to deflect that.

If you're dealing with businesses where compliance is required, such as PCI, HIPPA, or FedRamp, legal sway is absolutely relevant. If you should have a breach and an associated fine, Amazon can easily push the blame (and the likely-company-breaking fines) back on you.

[deleted]

Re: Serverless: slower and more expensive

#465
post #162

Earlier quoted context omitted.

Agreed. ~2 years ago I seriously looked into Serverless and very quickly discarded it after seeing a large production deployment of it. I didn't have access to the billing info but the site loaded much slower than a regular site and developer productivity was quite low. I'm going to stick with good old servers for now. If anyone is curious, a few years ago I did a write up on "Should your next project be built as a S…

Hey nickjj, you may want to update your blog post to reflect that the Lambda timeout is now 15m, not 5m.

Hi, thanks for the heads up. I just updated it.

Re: Serverless: slower and more expensive

#466
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…

We’re using Serverless where it fits and carrying on with our lives. I don’t feel the need to try and defend tools, because it’s exhausting. There are certain load graphs for which regular servers can’t follow the line in time, some for which regular servers can follow the line but would result in overprovisioning, and some in which request isolation is just a great thing to have. For these loads we use Serverless, for the rest we use normal EC2 or ECS.

Just understand the job and use the right tool for it. This fighting over Serverless and servers is like arguing over whether hammers or screwdrivers are better tools.

Re: Serverless: slower and more expensive

#467
Anyone who wanted to deploy easy should either prefer a hosted/low code solution or something similar to GAE/Heroku.

The deal with server less is that while it looks attractive, it, like many AWS products, is great for starting out but often not helpful when running anything for large workloads. Then it turns really expensive.

Re: Serverless: slower and more expensive

#468
post #393

Earlier quoted context omitted.

I will argue the opposite. Startups take on enough risks as it is. Unless your startup requires or is about a novel architecture. Why add more risks with non battle hardened technology. Software professionals often sees benefits without understanding the tradeoffs.

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.

Re: Serverless: slower and more expensive

#469

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…

Everytime I read these types of articles, I immediately login to AWS billing console and review our costs. We switched to AWS serverless about a year ago (API gateway and Lambda) and there have been no real surprises. I've been able to increase our contractual SLA uptime to customers (and charge for it). We can kick-off more backend async processes and let the magic of auto-scaling just do it's thing. If anything, I…

Those SRE infra skills pretty much crossover with knowing what your app is doing in FaaS environment.

How do you know those async requests are completing? What's the percentage of failures? Are you meeting those SLAs? Who's patching the code? How do you test and deploy new versions?

Those are all typically seen as ops tasks, now you're doing them.

Small bit of concern around you saying you're using the console, because good testing generally requires Infrastructure as Code, but I suspect the reality is your operational readiness meets your risk profile. That or you're winging it ya big cowboy. :p

Re: Serverless: slower and more expensive

#470

Earlier quoted context omitted.

It’s rare for things to go so disastrously wrong that legal sway is relevant. What’s much more common is an angry CTO looking for someone to be mad at, and Amazon doesn’t have any particular ability to deflect that.

If you're dealing with businesses where compliance is required, such as PCI, HIPPA, or FedRamp, legal sway is absolutely relevant. If you should have a breach and an associated fine, Amazon can easily push the blame (and the likely-company-breaking fines) back on you.

[deleted]
Post reply on HN