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

451–460 of 733 posts

Re: Serverless: slower and more expensive

#451

Post by richmarr »

vkou wrote: post #403
sgustard wrote: post #374

Earlier quoted context omitted.

> top-down organisational pressure created by technically incompetent strategic management Do most people work in this kind of environment? At my company our management couldn't care less what technologies we use. They want to see reasonable cost and solid uptime, and they ask engineering to deliver that.

Imagine a new CTO or middle manager coming in, with a small ego, and a big need to prove himself, and initiating a make-work project. What defense mechanisms does your firm have against this? Unless your team leads are golf buddies with the C-suite, it is unlikely that their opinions are going to be taken seriously.

How would your hypothetical defence mechanism tell which C-suite initiatives are worthwhile, and which are ego driven make-work?

Re: Serverless: slower and more expensive

#452

Post by oppositelock »

missosoup wrote: post #300
tus88 wrote: 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…

I spend six figures a month in AWS, on a mix of servers and serverless.

Serverless is more cost effective for sporadic, bursty things where the cost of an instance sitting idle outweighs the more expensive per-operation costs of serverless. On sustained load, it is almost never cheaper.

Another price to pay is complexity; it's simply more difficult to build, deploy, and monitor serverless systems.

Re: Serverless: slower and more expensive

#453

Post by brillout »

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…

> Tech should be about results, it should not be a religion.

I couldn't agree more with this.

I'm trying to get a small library [1] I wrote popular and it's insane how much resistance I get because it doesn't fit the "mainstream religion" of using GraphQL.

People are brainwashed to think API = REST or GraphQL. How many times did I see a RESTful (or even worse GraphQL) for an internal API where RPC would be so so much simpler... (GraphQL is great for third parties but sh*t for internal stuff.)

[1]: https://github.com/reframejs/wildcard-api, a RPC library for Node.js server Browser.

Re: Serverless: slower and more expensive

#454

Post by TheCoelacanth »

scarface74 wrote: post #386
mywittyname wrote: post #316

Earlier quoted context omitted.

Fargate is not a replacement for Lambda. While there's some capability overlap, each have their own respective niches.

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…

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.

Re: Serverless: slower and more expensive

#455

Post by falcolas »

SpicyLemonZest wrote: post #337
falcolas wrote: post #314

Earlier quoted context omitted.

Shifting blame doesn’t help much when you lose customers (or pay financial penalties) due to non—compliance. You learn quickly that while AWS is “compliant”, they have enough legal sway to never be on the hook if they aren’t actually compliant.

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.

Re: Serverless: slower and more expensive

#456

Post by thramp »

zeawee wrote: post #102
atroche wrote: post #88

Earlier quoted context omitted.

The Rust runtime has a fast start time as well, FWIW.

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.

Re: Serverless: slower and more expensive

#457

Post by kragen »

kstrauser wrote: post #365
missosoup wrote: post #300

Earlier quoted context omitted.

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

An example of where serverless is lovely for us : We run on AWS. We log lots of stuff to CloudWatch. CloudWatch allows you to scan for regexps (more or less) and send matching lines to a destination of your choosing. There are about 5-10 such matching events per day that we care about, and when they happen, we want an alert in a Slack channel (or email or text or PagerDuty or...). Option A: Stand up a server. Deploy…

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

Re: Serverless: slower and more expensive

#458

Post by bcyn »

NicoJuicy wrote: post #149
coldtea wrote: post #69

Earlier quoted context omitted.

> We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) That goes without saying! That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before. I don't think anybody uses things like AWS or serveless…

> it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before Perhaps it's more related to the programmer than the tech stack... It's also not solely developping, but debugging too. And serverless does make things a lot harder.

Why does serverless make things a lot harder? I'd argue that the stateless nature of serverless actually makes it much, much easier to debug.

Re: Serverless: slower and more expensive

#459

Post by bradstewart »

missosoup wrote: post #300
tus88 wrote: 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…

I use both Lambda and EC2 a lot. The decision on which route to go for a particular service/feature/app is pretty straight forward for me: need to support high loads or super low latency? EC2. Low volume, unknown/unpredictable loads? Lambda.

Re: Serverless: slower and more expensive

#460

Post by mic47 »

AdrianB1 wrote: post #54
mic47 wrote: post #21

1350$ per month is still fraction of salary of developer. So if it saves you that fraction of your (or your colleagues) time, it is definitely worth it.

1/10 and 1/100 are both fractions. If 1/10 of the salary of a developer is saving 1/100 of that developer's time, you lost. Fractions are not equal, blanket statements about fractions are not good business practice.

that is why I wrote "that fraction", hoping that it means that its the same fraction.

Though, your example still does not mean you lost. that 1/100 time is time that developer is not working on something else, that might be worth much more (though if ita 1%, its less likely. but my point is that developer time is more valuable than proportional amou t of his salary).

Post reply on HN