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

411–420 of 733 posts

Re: Serverless: slower and more expensive

#411

Post by LunaSea »

nailer wrote: post #373
LunaSea wrote: post #331

Earlier quoted context omitted.

> No, the lockfile does that. No, your lockfile doesn't care about build steps so any post-install script might run differently for the many other reasons listed. > Agree, but how much does one Linux+systemd different from other Linux+systemd? How much does the FS? Plenty. For example filesystem change events are known to have filesystem and OS dependent behaviours and quirks / bugs. When a Node module runs a shell c…

> > > my dependencies might be different > > No, the lockfile does that. > your lockfile doesn't care about build steps Then you're not talking about dependency versioning are you? you're talking about install order. In practice it hasn't been an issue, I should find out how deterministic install order is but I'd only be doing this to win a silly argument rather than anything that has come up in nearly a decade of ma…

> Then you're not talking about versioning are you? you're talking about install order.

I didn't mean build order but install scripts and native module builds.

The first type can create issues when external resources are downloaded (Puppeteer, Ngrok, etc.), which themselves have different versions or that fail to download and where the Node.js module falls back to another solution that behaves slightly differently.

The second type can occur when you have say Alpine Linux that uses MuslC and Amazon Linux uses GCC or when the native module tries to link with a shared library that is supposed to exists but doesn't.

> Are you generally proposing it would be common to use an entirely different OS? Or a non-boring extX filesystem?

I haven't checked but Amazon Linux by default uses XFS on EBS disks so I wouldn't be surprised if Lambda's used the same. So not a boring extX filesystem. ZFS is also relatively common.

> Serverless exists precisely to answer the question.

No, it clearly doesn't because your function will fail in local and succeed in Lambda, or the reverse, exactly due to the issues I mentioned in my various comments here and you will be left debugging.

Debugging which starts by finding exactly the differences between the two environments which would have been solved by a VM or Docker.

Re: Serverless: slower and more expensive

#412

Post by shiftpgdn »

tgeek wrote: post #347
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…

Hi there, Hey there, I lead Developer Advocacy at AWS for Serverless ( https://twitter.com/chrismunns ). I'll give you that this 80% number seems pretty out there. I don't know how that is measured or what it would be referencing. If you step back and remove all the commercial software from the argument (something like 50%+ of enterprise workloads, the kind of things you buy from a 3rd party and just run it, like Sha…

Kinda wild in your post history you're advocating for AWS as a cheaper superior platform without disclosing that you work there.

Re: Serverless: slower and more expensive

#413

Post by kraig911 »

I really think we're talking about things the wrong way. The argument shouldn't be slower/more expensive. Use the right tool for the right job. If it's simple REST don't use serverless. It's CPU bound stuff like generating thumbnails, parsing xml/json or file conversion is where serverless helps.

Re: Serverless: slower and more expensive

#414

Post by lallysingh »

mytailorisrich wrote: post #397
kstrauser wrote: post #365

Earlier quoted context omitted.

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…

If you have spare capacity on a server you can probably squeeze in such functionality at no extra cost.

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.

Re: Serverless: slower and more expensive

#415

Post by mytailorisrich »

lallysingh wrote: post #414
mytailorisrich wrote: post #397

Earlier quoted context omitted.

If you have spare capacity on a server you can probably squeeze in such functionality at no extra cost.

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

Re: Serverless: slower and more expensive

#416

Post by kstrauser »

mytailorisrich wrote: post #397
kstrauser wrote: post #365

Earlier quoted context omitted.

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…

If you have spare capacity on a server you can probably squeeze in such functionality at no extra cost.

But that makes operational expenses go up. For instance, now you have to tweak the Nginx config to support the service that normally lives on that machine and the new system. And you still have to write and maintain the web service driving it (which may not be hard, like a Flask app with a single route, but still more than zero). And you still have to maintain the server itself, which should involve regular OS updates and any work you have to do to automate deployment of the web service, unless you really like doing all that stuff by hand.

Or you can upload a single function definition to Lambda and let it do everything else.

Again, I wouldn't use Lambda for everything, but I'll gladly let it handle the stuff I won't want to bother with.

Re: Serverless: slower and more expensive

#417

Post by munns »

shiftpgdn wrote: post #412
tgeek wrote: post #347

Earlier quoted context omitted.

Hi there, Hey there, I lead Developer Advocacy at AWS for Serverless ( https://twitter.com/chrismunns ). I'll give you that this 80% number seems pretty out there. I don't know how that is measured or what it would be referencing. If you step back and remove all the commercial software from the argument (something like 50%+ of enterprise workloads, the kind of things you buy from a 3rd party and just run it, like Sha…

Kinda wild in your post history you're advocating for AWS as a cheaper superior platform without disclosing that you work there.

Yup! Haven't done it in years and created this different account to be more clear/direct in who I am. That is also why I called it out at the start and bottom of all my responses.

Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns

Re: Serverless: slower and more expensive

#418

Post by cdelsolar »

scarface74 wrote: post #260
dragonwriter wrote: post #243

Earlier quoted context omitted.

> Heroku is not Serverless in the modern definition of the word Heroku seems to be serverless in the way cloud vendors, including Amazon, have been using it recently; it's not serverless in the sense that Amazon first introduced it, which was a synonym for Lambda. It's pretty similar to GAE, which is definitely within the current usage of “serverless”.

Heroku is just an easier way to deploy to servers. It doesn’t scale down to zero, scale up as needed, etc. You still have distinct servers that you know about, can manage. S3, Fargate (Docker), DynamoDB, even SNS/SQS are considered Serverless by AWS’s nomenclature.

i'm not sure Fargate is considered Serverless.

Re: Serverless: slower and more expensive

#419

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

#420

Post by inimino »

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.

> most people choose it for reasons other than hype

[citation desperately needed]

Post reply on HN