Serverless: slower and more expensive • Hacker News Board

Re: Serverless: slower and more expensive

#471

Post by owenmarshall » Mon, Sep 23, 2019, 5:16 PM UTC

falcolas wrote: post #455

SpicyLemonZest wrote: post #337

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.

AWS' compliance model isn't a magic wand that makes your crappy app's XSS vulnerabilities go away. The real question: do you think AWS will try to push responsibility for a breach to their customers unjustly?

If you don't adhere to the shared responsibility model and a contractor checks long lived IAM credentials into Github, that breach is definitely attributable to you and you deserve all the "blame" you get.

But if someone figures out how to trick AWS' IAM into issuing credentials that allow PHI to be pulled out of S3, do you think that gets passed along to a customer?

Re: Serverless: slower and more expensive

#472

Post by scarface74 » Mon, Sep 23, 2019, 5:18 PM UTC

TheCoelacanth wrote: post #454

scarface74 wrote: post #386

Earlier quoted context omitted.

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.

How so? With lambda you give AWS a zip file with your code in it and with Fargate you give AWS a Docker Container. The only difference is that AWS doesn’t support the event triggers with Fargate out of the box.

Re: Serverless: slower and more expensive

#473

Post by k__ » Mon, Sep 23, 2019, 5:21 PM UTC

guitarbill wrote: post #406

k__ wrote: post #351

Earlier quoted context omitted.

Yes, it's unusable on macos and windows. Hopefully WSL2 will solve this.

Docker largely works fine on macOS? At least for testing, haven't run into any issues other than bad filesystem performance if you're writing a lot of data to a mounted FS. Our team uses it daily - a far cry from "unusable".

Maybe you just got a higher pain tolerance or better machines?

Re: Serverless: slower and more expensive

#474

Post by RhodesianHunter » Mon, Sep 23, 2019, 5:22 PM UTC

missosoup wrote: post #377

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…

> And so for data processing/streaming/batch [...] serverless actually does work out pretty well. This is my field of expertise. Serverless in the sense of lambda/functions is not usable for serious analytics pipelines due to the max allowed image size being smaller than the smallest NLP models or even lightweight analytics python distributions. You can't use lambda on the ETL side and you can't use lambda on the que…

Clickhouse is a really strange thing to compare to Lambda here. One is a method of performing small compute jobs, the other is an analytics database. They serve vastly different functions and saying "Clickhouse or postgres is cheaper and more performant than lambdas" is nonsensical.

Re: Serverless: slower and more expensive

#475

Post by matchagaucho » Mon, Sep 23, 2019, 5:24 PM UTC

ownagefool wrote: post #469

matchagaucho wrote: post #434

Earlier quoted context omitted.

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

AWS Cloudwatch pretty much delivers every metric imaginable.

Whether leasing EC2 servers or running serverless Lambdas, the logs all rollup to the same place.

We're gradually using more AWS CLI for things like deployment and policy management. But the console is sufficient for 80% of Serverless DevOps.

Re: Serverless: slower and more expensive

#476

Post by z3t4 » Mon, Sep 23, 2019, 5:24 PM UTC

scarface74 wrote: post #134

z3t4 wrote: post #53

Serverless is a cool solution looking for a problem to solve. However much I want to use it, eg. not having to manage servers myself, I can't find any use case where it would make sense.

Well, millions have. So obviously someone has found a problem it will solve...

A million people using using serverless? Do you have a reference ?

Re: Serverless: slower and more expensive

#477

Post by thisisnico » Mon, Sep 23, 2019, 5:24 PM UTC

This is interesting. I'm guessing the Dev-Ops (Cloud infrastructure people) are going through the same thing as what I, an on-premise infrastructure guy had gone through already. Everybody was preaching Cloud at the beginning. It was slower, it was more expensive. Now look how much cloud had grown and had improved. I believe the same will happen with serverless. A lot of the cloud infrastructure will be abstracted from you. All that will be left are software developers / engineers managing everything. Lowering the requirement of having Ops people. - Coming from an Ops person.

Re: Serverless: slower and more expensive

#478

Post by noobiemcfoob » Mon, Sep 23, 2019, 5:26 PM UTC

johnfactorial wrote: post #286

rdsubhas wrote: post #114

This is how a conversation with a colleague who were enthusiastic about Serverless, and who's company was mostly on Java/JVM stack went: Colleague: Lambda is awesome, we can scale down to zero and lower costs! We love it! We use cool tech!! Me: What did you do about JVM warm up? Colleague: We solved it by having a keepalive daemon which pings the service to keep it always warmed up. ... Me thinking: Uhh, but what abo…

> Lambda seems to be a fast prototyping tool. My thoughts EXACTLY. The great power in "serverless" architecture (i.e. AWS Lambda + AWS RDS + AWS Gateway) is how it empowers prototyping a new product. Counterintuitively, it's future-proofing. You should know in advance that it's too slow & expensive. But you get to spin up a prototype backend very rapidly, pay only for what you're using while prototyping, and Lambda's…

It's the same argument for Python over C development. Prototype in python and migrate portions to C as performance is needed. You'll often find that large portions of your codebase will never need to migrate out of the "prototype" stage.

Re: Serverless: slower and more expensive

#479

Post by kstrauser » Mon, Sep 23, 2019, 5:28 PM UTC

kragen wrote: post #457

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…

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

Yep, you figured me out. Drat!

Re: Serverless: slower and more expensive

#480

Post by myrandomcomment » Mon, Sep 23, 2019, 5:29 PM UTC

cthalupa wrote: post #380

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…

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

I agree. All I have done for the past 15 years is startups and I love HN, however in the last few years it has become very apparent there is a selection bias to people in startup/valley type tech. I spend a ton of time explaining to my CEO and CTO why a customer cannot just dump that old way and embrace the new hotness. The valley culture is a bubble and does not reflect that of real world IT in general. Still love HN.