Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

331–340 of 733 posts

Re: Serverless: slower and more expensive

#331
post #298

Earlier quoted context omitted.

Lambas are not simple functions because your environment is different in local compared to production. If I run a Node.js function in AWS Lambda, my Node.js version might be different, my dependencies might be different, the OS is different, the filesystem is different, so I or one of my node_modules might be able to write to /tmp but not elsewhere, etc. It's the reason people started using Docker really. If you don'…

> Node.js version might be different Yes, in major only. Your lambda has node 10, you might be running 10.x or 10.y > my dependencies might be different No, the lockfile does that. > the OS is different, the filesystem is different Agree, but how much does one Linux+systemd different from other Linux+systemd? How much does the FS? > It's the reason people started using Docker really. VMs, docker and having to care ab…

> 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 command, it's possible that you have a BSD vs a GNU flavour of a tool, or maybe a different version altogether.

The Linux user with which you are running the function might also have different rights which could become an issue when accessing the filesystem in any way.

> VMs, docker and having to care about and manage isolation platforms is the reason people started using serverless.

Maybe, but serverless doesn't answer those questions at all. It just hand waves testing and vendor independent infrastructure.

Re: Serverless: slower and more expensive

#332
post #241

Earlier quoted context omitted.

> Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy. It shifts blame, especially if it's in the contract with the provider.

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.

Yup! If something goes wrong with compliance, who is going to win the finger pointing game? A smaller company that needs to outsource their compute, or Amazon?

Re: Serverless: slower and more expensive

#333
post #69

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…

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

They can be a lot cheaper. Maybe only in some cases but then it can make a difference.

Re: Serverless: slower and more expensive

#334

Earlier quoted context omitted.

Do you have any resources on testing a Lambda? When I was fooling around with it, the only thing I ran into was that AWS Sam-client or whatever. Thing looked like an absolute nightmare to get up and running.

I've found unit testing to work fine for Lambdas. The biggest difference between running as a Lambda and running locally is the entry point. With a Lambda you have an event payload that (usually) needs to be parsed and evaluated. I'll typically write all the core functionality first, test it, then write the lambda_handler function.

But how do you test lamba_handler then? Without a way to run lambdas locally, this sounds like a big black hole in your infrastructure.

Re: Serverless: slower and more expensive

#335
post #249
post #237

Earlier quoted context omitted.

I found SAM to be extremely difficult to use, especially on windows where docker is just plain old terrible.

True. I stopped using windows for dev machines long time ago, but I'd guess with the Linux subsystem stuff it will catch-up in the next years.

I honestly have no problems developing on windows (except when my macos coworkers dont consider windows). Docker is the only real issue.

Re: Serverless: slower and more expensive

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

Because comment sections are not good measures of opinion - they are places for discussion.

People make more effort to engage if they have strong positive opinions and minor negative opinions. Minor positive opinions, which (you hope) are the average in an audience, get unrepresented if the effort required to give feedback is great. That's why metrics measuring average opinion - like NPS - aim to require as little effort as possible.

Re: Serverless: slower and more expensive

#337
post #241

Earlier quoted context omitted.

> Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy. It shifts blame, especially if it's in the contract with the provider.

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.

Re: Serverless: slower and more expensive

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

> HN is usually a pretty good gauge for how the wider engineering community feels about a particular technology.

Source?

Re: Serverless: slower and more expensive

#339
post #263

Earlier quoted context omitted.

But they do go away. They go straight away to a vendor which is very likely to address them faster, and with more competent resources, than you and your team (or, if that sound insulting - me and my team). They become covered with that famous someone else's problem field

> They go straight away to a vendor This argument only works until you reach a certain size or security requirements. At the end of the day, if it's critical to the business it doesn't matter what the paper says, you're still responsible for any damage to the business from a bad vendor. ---- It's just like car manufacturers, nobody cares that Takata was actually responsible for faulty airbags. They simply know their…

But, at that same “certain size”, shareholder value for your company becomes something influenced mostly by making your value-chain upstream/downstream partners happy, not by making the eventual customers of your product/service happy.

Rather than thinking about GM’s perspective, think about Takata’s perspective: they screwed up making an airbag, but everything was fine because they outsourced their audit to GM, so indeed it was “GM’s responsibility.” On top of that, GM is still happy to treat them as a partner.

Now imagine that instead of some random third-party supplier, Takata was a division of GM, selling to a different division of GM. The same considerations still apply from the Takata-as-division’s perspective, even though nominally they’re part of a company of that “certain scale.”

Re: Serverless: slower and more expensive

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

Odd that you demand a citation and then counter with 3rd party anecdotes.
Post reply on HN