Live data from Hacker News

Back to the '70s with Serverless

evrl.com

71–80 of 310 posts

Re: Back to the '70s with Serverless

#71

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…

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

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

Not using serverless doesn’t mean there can’t be a CICD pipeline.

Re: Back to the '70s with Serverless

#72

Earlier quoted context omitted.

Why is the alternative to serverless, colocating servers in a DC? The alternative is renting VMs from those same clouds. It works fine and is cheaper when you work on software that actually has users. It also doesn't result in the cloud provider cramming a crappy under-baked programming model down your throat. Per request pricing and "scaling to zero" is just old fashioned unbundling. You are selling a smaller quanti…

> Why is the alternative to serverless, colocating servers in a DC? Because that’s what the author was comparing it to. Yes you can rent vms, and that works for many workloads. However serverless platforms provide other benefits like deployments, load balancing, and auto scaling that you’d need to setup yourself on raw vms. Plus, with services like AppEngine Flex you can run serverless on vms to cut costs if you have…

I agree. I am working on a devops team that has assembled a half decent CI/CD infrastructure for widespread use at our company of 600 devs and thousands of apps. We are on our second iteration, which is even leaner and more invisible to the devs. However, we are seeing a move to serverless would be a net gain for all involved, specifically the scale to zero and not caring about the container and kubernetes configuration.

Re: Back to the '70s with Serverless

#73
post #45
post #11

Earlier quoted context omitted.

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

Is being paid hundreds of thousands of dollars plus stocks and bonuses not enough of a reason to show up at work?

Re: Back to the '70s with Serverless

#74
post #73
post #45

Earlier quoted context omitted.

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

Is being paid hundreds of thousands of dollars plus stocks and bonuses not enough of a reason to show up at work?

You would think so, but as it turns out, it’s not. First world problems^2.

Re: Back to the '70s with Serverless

#75
> Split your codebase, split your teams, create a lot of opportunities for mediocre coders to grow into mediocre engineering managers, everybody was happy.

Too many companies have to hope of hiring the level of competence required to not suck. It's painful but true. AWS is cheap and serverless is popular when setting up a linux image security and correctly can take weeks or months.

Re: Back to the '70s with Serverless

#77
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.

> Cloud is an expensive, overly complicated, lock-in boondoggle.

Only if you go with companies that make it such.

Renting web hosting on someone's collection of rack-mounted systems running some well-known OS is Cloud, and there's nothing inherently bad about that, unless you've defined Cloud to mean "Only The Bad Stuff About Using Computers Other People Own". You can run things like they were run in the 1990s, complete with Apache and mod_perl CGI and MariaDB swapped in for MySQL and everything held together with shell scripts and run via ssh and ftp. No magic, no lock-in, no complexity beyond what every other serious general-purpose computer system is these days.

I agree that Big Cloud Providers layer on pricing models and whatever middle-management-ware they can come up with to obfuscate the underlying mechanics, but if you're against that, say so. Don't catch everything in your blast radius because it reduces the overall impact.

Re: Back to the '70s with Serverless

#78
post #73
post #45

Earlier quoted context omitted.

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

Is being paid hundreds of thousands of dollars plus stocks and bonuses not enough of a reason to show up at work?

Not when that becomes table stakes, no. If you have five different companies offering you that kind of money, eventually you'll start thinking about more than just the money.

Re: Back to the '70s with Serverless

#80
post #11
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…

I think it's sad that the vast majority of people in our field (at least in my experience) is so damn excited about building new stuff all the time. There's no appreciation for maintaining, optimizing, and improving existing systems. There's only talk of "adding value" but very little of "keeping value."

So people keep moving on to the next project, leaving the old ones running live but to rot, and at best every once in a while someone will be assigned the dreadful task of having to figure out why the "legacy" (even though it's still fully in operation and servicing customers) system had an outage and can't recover.

Our field suffers from a serious lack of focus. People don't learn to work under constraints. Instead, they prefer to build a whole new thing, full of complexity and hidden issues, just to get around a few nuisances that, with the right mindset, actually force one to be creative (which should make work fun).

I've recently commented here on HN about how I feel like I'm outside the norm on these things [0]. I was happy to learn I'm not alone. I do think those of us who don't mind working on "legacy" systems and perhaps with limited tools are the minority though.

Sometimes it's not even about working on old systems. You work with current tech, build something, and as soon as it's barely deployable, you're expected to move on to the next thing. "It's a great opportunity for your career," they say, "you're gonna get to build something new and make key decisions."

Why does it have to be decided for me? It's my current predicament. I'm working on a project that took me two months to get in the right mindset for and get all the context I needed. I had to try things out, sort out ideas, until I got a clear picture of what to build. Now I've built the first iteration of it. It works, and I'm super excited about it. But it's not done by any means. It needs more features. It needs to be polished so it doesn't make operations miserable running the thing. And yet... I have to move on, and hand it over to someone who doesn't have the same excitement for it that I have, and has maybe 10% of the context.

All because building new things (and adopting The New Hotness, as you say) is what "everyone" wants.

[0] https://news.ycombinator.com/item?id=25404039

Post reply on HN