Live data from Hacker News

2023 DevOps Is Terrible

abidmoon.hashnode.dev

101–110 of 126 posts

Re: 2023 DevOps Is Terrible

#101
post #34

If you have a DevOps team, your company probably doesn’t understand what DevOps is about.

Given that everyone and their mother has slightly nuanced yet disperate definitions of exactly what devops is , I'm not sure. DevOps? Oh you mean the developer experience people? DevOps? Oh, the build pipeline people? DevOps? Oh, the people who handle the cloud? DevOps? Ah, you mean those folks who handle our observability! DevOps? That's Katya, she's a developer but i'm not sure what she does except act stressed out…

Hint, in my definition it’s none of the above

Re: 2023 DevOps Is Terrible

#102
Sysadmin, devops, platform eng all suffer from made up problems.

What’s IAM?

Access control.

What’s a firewall?

Access control.

What’s a route table?

Access control.

What are resource limits and reservations?

Access control.

Yet years of legacy solutions has us discussing all these things as if they are fundamentally different. User management comes wrapped in vacuous jargon. Network addressing schemes are completely design by the pocket protector committee (fuck off they can be wrapped in abstraction that is less obtuse jargon and more memorable/mnemonic).

There are no users, groups, or network routes in the machine. Devops is obtuse access control because a lot of companies can make money from insuring its obtuse access control.

Re: 2023 DevOps Is Terrible

#103

Sysadmin, devops, platform eng all suffer from made up problems. What’s IAM? Access control. What’s a firewall? Access control. What’s a route table? Access control. What are resource limits and reservations? Access control. Yet years of legacy solutions has us discussing all these things as if they are fundamentally different. User management comes wrapped in vacuous jargon. Network addressing schemes are completely…

Calling a route table "access control" is not useful.

It's not access control, it's literally in the name, it is about navigation of the network via routes.

As for your comment about the "pocket protector committee" that's just ad hominem attacks on the people that keep the internet running.

Saying that NDP is more complicated than ARP/RARP etc because it has a different name is, again, attacking actual needs because it's more complicated than the protocol it replaces.

A network ACL is access control (it's in the name), L2 VLANs may be used for network separation, but they're also used for switches to be able to not have to broadcast packets across all their ports.

If you want to downplay the different requirements that the different forms of resource management require as "access control", then all you're doing is removing all meaning from the term "access control" in the first place.

Re: 2023 DevOps Is Terrible

#105
Devops got stunted or intermingled with the great migration to the Cloud. It could be practiced on any level of infrastructure, but the discourse currents of the Cloud were too strong.

Re: 2023 DevOps Is Terrible

#106

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

And some devs do learn how Linux works but don't want to waste their time memorizing how shitty $DEVOPS_PRODUCT that'll be replaced in two years works. :D

As someone that knows how several UNIX variants have worked since I used Xenix in 1993, those devs usually learn how a specific Linux distribution works, place them in another work, and they will be hunting for configuration files, init systems, daemons and what not.

Same applies to me, "knowing" GNU/Linux since Slackware 2.0.

Re: 2023 DevOps Is Terrible

#107

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…

Maybe in FAANG it's "back like we are in 2015" but the tools that have been brought into the mainstream like Kubernetes, automation tools and such have had a great impact across many small to large sized organizations. It's done a great job to enforce consistency and immutable infrastructure in a way that is more approachable for most when you get past the scale of a few resources. I've seen start ups write their on…

> but the tools that have been brought into the mainstream like Kubernetes

unless you are running real steel, kubernetes is at best a complication layer over the underlying cloud tools. In 2018 me and my team built a real time, ML-based processing API. It was hugely scalable, optimised for speed, price and uptime.

At no point did we use need to use kubernetes. Not only would that have eaten most of our innovation budget, all it would have done is add latency and driven up the money we spent on inter VPC transfers.

> I remember the days of Nagios, Zabbix, SolarWinds etc

So do I, they were recognised as shit even in 2015. $work allowed me to lead the migration away from them and by then we were half way through replacing most of splunk with graphite/grafana based metrics instead. The rest of the alerting was mostly handled by a custom inhouse /__status end point parser.

> The previous iteration of platform at this company was all self-managed VMs with the old school sysadmin mindset. They were managing hundreds of VMs by hand or using some light ansible that was retrofitted to work with pre-existing machines, we were using corporate F5 load balancers and VMware which are immediately out of date the moment you deploy them.

That, again, is just bad sysadmin. Unless you have complete control over your stack with ansible, then its not ansible, its just sparkling bash script.

I worked at a VFX company that deployed to all real machines for virtually everything. They used a GNU configuration system that was older than SSH (I can't remember what its called, it used to use rsh, that's how old it was.) All the machines were fungible, We could replace a file server at the drop of a hat (the only limit was how fast we could copy 160tbs over 2x10gig nics) Most of the place ran on perl, in one git repo for just configuration. OS updates were applied weekly, and we pushed system changes daily. This was in 2013.

salt made all of that easier, especially as we had way too many hosts to sensibly run ansible at the time(I think we worked out it would take >1day to run a basic role).

They had automated it to the point that you could plug in an unconfigured blade host, turn it on, and within 30 minutes, the bios was updated, networking configured and each blade was starting to be installed.

Automation is an attitude. You can either invent new tools to solve hypothetical problems badly (k8s supposedly is high scale, but cant practically get above 1k hosts, its also balls deep in ipv4 ), or actually use/create tools to solve the problems you have now.

Re: 2023 DevOps Is Terrible

#108
post #86

Earlier quoted context omitted.

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

Sorry, but how did you manage to make so many assumptions from that? Everything I need from Ops is already enumerated and specified more than well in tickets (which is required, as is par for course with the sysadmin from hell stereotype), and documented in Markdown files within my app's source code. I generate scripts for them since that's what they WANT and ASKED for several times. They literally want me and other…

> I can't change other people's behavior. I can only change mine.

Ah my friend, you totally can change other people's behaviour. go on. hug an ops, sit next to them and work with them. show them a bit of love and make them feel part of the team. Think about it from their view, why don't they trust your scripts?

Why dont they feel empowered to spin up a staging area? is it a skills gap? fear? or do they not feel confident enough to ask.

It sounds like solving their problem will also solve yours....

Re: 2023 DevOps Is Terrible

#110
post #39

DevOps is terrible because we want to have a team of fullstack expert engineers that have certs in every tech, but pay them for a single role. First there are not enough ppl with that huge landscape of knowledge. Second you would have to pay a salary of 5 ppl i.e. 500k/y to make ppl willing to spend that much time on work.

There are more people than you think that can slap together some YAML and a Helm chart and deploy something reasonably resilient inside a Kubernetes cluster.

I've been around for the cloud migrations in every phase, what we have today with Kubernetes is miles better than the maze of Puppet and other crap we had 20 years ago.

Post reply on HN