Back to the '70s with Serverless • Hacker News Board

Re: Back to the '70s with Serverless

#41

Post by thethethethe » Sun, Dec 20, 2020, 3:01 AM UTC

mattmanser wrote: post #8

cs702 wrote: post #5

> So what have we now? A “mono repo” codebase, because clearly a Git repository per function in your system would be too much, a large deployment descriptor per fine-grained component, which Spring maybe called “Controller” but is now called “Function”, and instead of combining them all on your desktop, you send them off to someone else’s mega-mainframe [AKA "the cloud"]. You deploy, get an error message, and login t…

Everyone's chasing "scalable", mostly for no reason at all. There's also this enduring myth you see repeated even here of how much saving there is by not having "devops", when only very big companies needed them in the first place. A few minutes per month is the most devops any startup would need to do in reality running their own VMs or servers, after an hour or two of setup. And that hour or two is often less than…

> There's also this enduring myth you see repeated even here of how much saving there is by not having "devops", when only very big companies needed them in the first place.

I dunno, the first company I worked at was very small, under 30 people, sales included, and I was hired on as an SA. If they were using serverless, they would not have needed to hire me.

Deployments and system upgrades were very toilsome. The dev lead would spend a few hours deploying new code and we’d only do it around midnight in case there was a problem (our customers were almost entirely US based). I spent a lot of my time automating OS upgrades on the web servers behind our proxy. All of this work would be unnecessary for that small company if they were using serverless.

Additionally, as mentioned before, the majority of their traffic was during the day so they could have scaled down automatically at night, cutting costs. Would this be cheaper than running machines 24/7? I’m not sure, but I could see why you’d be interested in at least looking into it

Re: Back to the '70s with Serverless

#42

Post by PaulDavisThe1st » Sun, Dec 20, 2020, 3:02 AM UTC

echelon wrote: post #14

"Cloud is the new mainframe" This is the message we've needed. Cloud is an expensive, overly complicated, lock-in boondoggle. Open source needs to rally hard to prevent cloud providers from running their tech.

TFA is talking about serverless, not cloud computing in general (e.g. rent a VM, run stuff in it).

I don't love that I pay aws to run my open source domain(s), but the extent of their job is: keep my VM up, provide me with outbound email that works, offer backups. For now, I can live with that.

Re: Back to the '70s with Serverless

#43

Post by FpUser » Sun, Dec 20, 2020, 3:06 AM UTC

cs702 wrote: post #5

> So what have we now? A “mono repo” codebase, because clearly a Git repository per function in your system would be too much, a large deployment descriptor per fine-grained component, which Spring maybe called “Controller” but is now called “Function”, and instead of combining them all on your desktop, you send them off to someone else’s mega-mainframe [AKA "the cloud"]. You deploy, get an error message, and login t…

>"Invariably, their response has been to tell me that I just don't get it"

I cured this one when my native server running on not so expensive multicore CPU with enough RAM left their cloudy setup in a dust performing more than a 100 times faster and still having huge potential reserve in vertical scalability. They were just astonished at what a single piece of modern hardware in combination with the native code could do.

Re: Back to the '70s with Serverless

#44

Post by thethethethe » Sun, Dec 20, 2020, 3:08 AM UTC

pram wrote: post #37

thethethethe wrote: post #15

> You deploy individual stateless functions. But not inside a Java monolith, that is old, but on top of a distributed system. You would have been laughed out of the door if you had proposed that in 2000, and you should be laughed out of the door right now, but such is the power of marketing. I’m sorry but this absurd and blatantly ignores the reasons why people choose serverless. No mention of scale to zero, virtuall…

lol. You are totally conflating 'serverless' with using the cloud, period. Not going with Lambda in AWS doesn't mean you can't use EC2, EKS, ECS, Elastic Beanstalk, and so on and so forth. You're the one spreading FUD.

I think you are miss understanding my comment. I was responding to the author’s comparison of serverless and the cloud to collocated servers in a DC, I never argued that other services in the cloud are bad/shouldn’t be used/inferior to serverless in all cases.

I suppose this wasn’t clear because another commenter had a similar question/response

Re: Back to the '70s with Serverless

#45

Post by muglug » Sun, Dec 20, 2020, 3:09 AM UTC

tyre wrote: post #11

cs702 wrote: post #5

> So what have we now? A “mono repo” codebase, because clearly a Git repository per function in your system would be too much, a large deployment descriptor per fine-grained component, which Spring maybe called “Controller” but is now called “Function”, and instead of combining them all on your desktop, you send them off to someone else’s mega-mainframe [AKA "the cloud"]. You deploy, get an error message, and login t…

I think what’s important to remember is that these kinds of “truth” are not the full story. Yes, a technology probably won’t live up to its marketing. Yes, what works is probably good enough. Yes, changing has switching costs and sacrifices institutional knowledge. Yes, we’ve seen these technologies before and switched away from them from various reasons. That’s all fine and sometimes frustrating as an engineer. But…

Thanks for putting this into words. People want a reason to log on, a reason to show up to work.

I wrote a blog post on Monday about a relatively old and not-hot language. The post nevertheless trended on Medium and received 50k views. A lot of the feedback was from people who were just happy to see someone senior say something positive about the not-hot language.

Anyway, working with The New Hotness also gives people something to put on their resumé: “I built system X on top of The New Hotness. Nobody had built such a system before for The New Hotness”.

Re: Back to the '70s with Serverless

#46

Post by apfsx » Sun, Dec 20, 2020, 3:09 AM UTC

"Yes, we run workloads that your nephew can run on his Raspberry Pi 4, but this is the future of enterprise."

This hit home... the amount of money I've seen businesses pour down the drain in my past few years of experience is insane. Offices with less than 10 people being talked into server setups costing tens of thousands of dollars for nothing more than a NAS, recoridng camera footage, Door access, etc.

Re: Back to the '70s with Serverless

#47

Post by FpUser » Sun, Dec 20, 2020, 3:12 AM UTC

empthought wrote: post #22

mattmanser wrote: post #8

Earlier quoted context omitted.

Everyone's chasing "scalable", mostly for no reason at all. There's also this enduring myth you see repeated even here of how much saving there is by not having "devops", when only very big companies needed them in the first place. A few minutes per month is the most devops any startup would need to do in reality running their own VMs or servers, after an hour or two of setup. And that hour or two is often less than…

> A few minutes per month is the most devops any startup would need to do in reality running their own VMs or servers, after an hour or two of setup. Right up until something crashes or some hardware fails.

I always have standby copy deployed elsewhere. And I make it a point not deploying production until a single script could rebuild new clean system by using backed up data, configs and software packages. So for me it is no a big deal at all. Well if the hardware died I have to pay for replacement which is not fun but it is a very rare occurrence.

Re: Back to the '70s with Serverless

#48

Post by desert_boi » Sun, Dec 20, 2020, 3:15 AM UTC

l0b0 wrote: post #18

> XML, however, was universally rejected in favour of things like JSON, Yaml, HCL, Toml - all free of structure, with zero indication whether a computer would find your prose gibberish or the next Shakespeare play until you actually pushed your code to some test cluster. There are a few fundamental differences between these languages, but it's just plain wrong to say that any of them are not "structured." Did OP mean…

By that logic, is https://json-schema.org/ is the reimposition of a schema within JSON?

Re: Back to the '70s with Serverless

#49

Post by mlthoughts2018 » Sun, Dec 20, 2020, 3:15 AM UTC

cs702 wrote: post #5

> So what have we now? A “mono repo” codebase, because clearly a Git repository per function in your system would be too much, a large deployment descriptor per fine-grained component, which Spring maybe called “Controller” but is now called “Function”, and instead of combining them all on your desktop, you send them off to someone else’s mega-mainframe [AKA "the cloud"]. You deploy, get an error message, and login t…

I find your quote here and the follow up seriously unconvincing. You know what a miserable workflow is? Preparing all my build scripts according to the half baked build tool that our in-house Deployment team cooked up to use fabric to spray my deployment onto a bunch of nodes in our data center, all the tests and script linting pass, so then I go push it through our CI/CD pipeline (which can’t do the above tests for me because again this is all threadbare maintained by in-house tooling teams who could not be less aligned to end product deliverables), and lo and behold it breaks. Good thing I’m not paying so much for CloudWatch so I get to literally go ssh to the worker node of the CI/CD system where my task failed and cross my fingers that it wasn’t reclaimed for the next task and that the log files weren’t rotated off, grep my way to tracebacks that probably involve things no one on my team has ever heard of, spend 1/2 a day chasing them all down (if I’m lucky), and finally kicking the box to restart a build a few times and it goes. Then it goes to the in house homebrewed kubernetes deployment scripts where it promptly chokes on a secret that wasn’t configured right (thanks home made script linters), so then I have to go down a rabbit hole of eye melting Helm config of secrets for an hour but thank god I’m not paying for a simple cloud UI for this. So we get the secret cleared up and everything is great, until the kubernetes scheduler can’t schedule my pods because our data center is at capacity and now I literally can’t get work done until I chase down some probably incorrect and certainly unmaintained Grafana chart of who is using how much excess memory on which nodes, and wrangle someone with authority to force another team to stop eating lunch and downsize pods right now. After all this, 6-7 hours later and 20-30 labor hours later, my workload is finally deployed, but it will die overnight for an uncaught reason that doesn’t alert anyone, and even if it did, the team managing compute resources is in a permanent state of PTSD from never ending pages so they wouldn’t bother caring about why my workload failed and will just assume it’s application logic bugs or Docker bugs on my side for as long as they can just to avoid yet another un-debuggable failure landing on their plate, so that’ll be great for morale in the morning when I get to derail yet another day and spend time doing every type of ops work that is not my job and prevents us from delivering product goals.

This is every company I’ve ever worked for or ever heard any colleagues, friends or associates work for, that tries to build their own SRE practice on top of data centers.

Large cloud platforms alleviate so so much of this pain. The “back to the 70s” workflow sarcastically described in the quoted passage you shared sounds like an absolute dream compared to the nightmare of shipping code on internally created developer tool & deployment platforms interfacing to bare metal or space leased from data centers.

I can’t give the cloud providers my money fast enough and I have only ever felt happy about that for years and years now.

Re: Back to the '70s with Serverless

#50

Post by sheeshkebab » Sun, Dec 20, 2020, 3:19 AM UTC

Lately, the main reason for using “serverless” (aws lambda in particular and all related wax) has primarily to do with security “compliance” at enterprises, cost of it in particular, and nothing with developer productivity or technology... aws just makes it super trivial and cheap to meet all the compliance requirements if using only this dilapidated stack.

It’s no wonder any startup with half the brain would still pick rails/ruby for actually creating something of value, while enterprise middle managers and bean counters argue about how to not write code.