Live data from Hacker News

2023 DevOps Is Terrible

abidmoon.hashnode.dev

51–60 of 126 posts

Re: 2023 DevOps Is Terrible

#51
I think the biggest issue with devops is that it originally meant "socialising" your sysadmins, by getting them to sit with your devs, so that shit didn't get lost because nobody thought to talk to the right team.

But then it morphed into "oh lets innovate with infrastructure" but the innovation turned into "lol lets just restart from scratch and ignore history" Anybody who used early k8s can attest to how un production ready it was for the longest time. It _felt_ like progress because it required a lot of (to dev eyes) hidden magic to make it work.

Now, we are back with sysadmins, but they are called SREs. They provide a platform, which devs talk to to deploy stuff.

Basically we're back where we were in 2015, just with more yaml.

The good things that have come out of devops has been the dashboarding and metrics tools. Its just a shame that everything else touched by it appears to be an infinite source of busy work (looking at you kubernetes)

(before anyone asks, I'm an SRE at a FAANG.)

Re: 2023 DevOps Is Terrible

#54
Yuck, Portainer... when I read that I get nightmares.

The problem is: when you give developers access to Kubernetes, to ECS, to Portainer, to whatever they. will. not. care. about literally anything. You'll find a hotpot of cobbled together Dockerfiles with zero provenance, with base images pinned to stuff years old, and completely inefficient layer ordering. Pipelines won't use caching or parallelism (okay, sometimes because they use Maven which is a clusterfuck on its own).

Software developers are developers, 90%+ will never have heard of how Linux works below the hood, how Docker actually works, they'll just copy and paste together stuff from Stackoverflow without even attempting to understand how it works.

And I don't even blame them. I can't, I don't want and I won't.

Companies, it's time to stop loading stuff onto your developers that they don't have to (have) any clue. JFC.

Re: 2023 DevOps Is Terrible

#56
post #41
post #2

The fact that we have a “devops team” at work infuriates me. It’s enough to distract me me from how “Scrum” has destroyed Agile.

The only thing I like about the return of sysadmins and the end of the "you build, you run it" culture of Devops it is that I'm 100% off the hook if something dies in the middle of the night. The so-called DevOps guys are stressed out of their marbles, but when the CTO calls me 4 AM I can't say anything but "Sorry dude, I'm not a clairvoyant. I have no permission to do shit in prod, call Ops or give me AWS access now…

> The fun part is Ops wants us engineers to help more, but they don't even trust (and some don't know how to run) my Terraform or CloudFormation scripts (I let them choose which), so they just read the tf/yaml and click AWS buttons manually. Often making lots of mistakes.

Yeahnah, you're part of the problem.

If you've not documented it properly, and more importantly, if the team are weary of prodfucking TF/CF scripts, there is a culture problem. You both need to understand how that works, if they don't have enough time, then you're understaffed, that needs to be fixed.

I worked at place that was going through a really painful ops->devops->dev oncall transition. Ops still had a shit ton of power, but nobody included them, and just shouted at them when stuff went red. It took a huge culture shift, and devs sitting in ops and doing a shift or two, to sort it out.

Re: 2023 DevOps Is Terrible

#57

I think the biggest issue with devops is that it originally meant "socialising" your sysadmins, by getting them to sit with your devs, so that shit didn't get lost because nobody thought to talk to the right team. But then it morphed into "oh lets innovate with infrastructure" but the innovation turned into "lol lets just restart from scratch and ignore history" Anybody who used early k8s can attest to how un product…

So you mean, DevOps has made Sysadmins more service oriented and now instead of having their pets and being in overprotective silos, they actually provide best practices and proper platforms for the poeple developing the software?

Re: 2023 DevOps Is Terrible

#58
post #31

Earlier quoted context omitted.

Can you expand on what you mean by this? Specifically: "you can't move the responsibility of operations away from the application teams without seriously compromising incentives that effect quality, throughput and reliability"

To be more blunt about it: if the person writing the code is not the one on the pager at 3am, they have no serious incentive to make it correct or resilient. This is why "you write it, you run it" is so important - the most reliable software is the software never written, but if something must be written, it's important that all incentives are aligned for it to work right. Of course, this is only at the operational e…

> To be more blunt about it: if the person writing the code is not the one on the pager at 3am, they have no serious incentive to make it correct or resilient.

The problem is in 99% not that the developers don't want to do correct code. The problem is that product/project management doesn't allocate the time and budget for clean development practices, proper QA, and refactoring because their metrics are revenue, releases/timeframe, or similarly useless/unsustainable.

Re: 2023 DevOps Is Terrible

#59
"DevOps" as in Developers being closer to Ops, or "DevOps" as in "I'm a shiny Golang outfit that is going to solve Real Problems TM with YAML and a bunch of templated-generated Golang?"

I realize this is a bit of an odd tangent, but I would love to hear cadey talk more about what "devops" means at a shop like Tailscale. Actually, as I type this, even more curious. I know some of those folks are cut-me-and-I-bleed-Go types, but I also know they're deep into NixOS for server management. It would be very interesting to hear more about how those intersect for their infra/server/dev culture.

Re: 2023 DevOps Is Terrible

#60
Most commenters here seem to ignore the fact that saas deployments have become increasingly complex over last decade in part bc low hanging fruit has been picked. Also the massive scale of even relatively no-name companies out there.

I'd add that most of the 1-4 "problems" (boo-hoo, managing IAM is boring for devs) OP mentioned as well as advent of so called "platform engineering" stem from one thing only - poor engineering leadership.

Post reply on HN