Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Eulogy for DevOps

matduggan.com

Post reply on HN
Print view View original

71–80 of 175 posts

Re: A Eulogy for DevOps

#71

Post by photonthug »

2 observations, first the cynical one, but the second is optimistic.

For leadership, the whole idea of "breaking down silos" is almost always lip-service, and to the extent that is/was a core mission of DevOps, it was always doomed. Responsibility without power doesn't work, so it's pointless unless the very top wants to see it happen. Strong CTOs with vision are pretty rare, and the reality is that the next tier of department heads from QA/Engineering/DataScience/Product are very often rivals for budgets and attention.

People that get to this level of management usually love building kingdoms, and see most things as zero-sum, so they are careful to never appear actually uncooperative but they also don't really want collaboration. Collaboration effectively increases accountability and spreads out power. If you're in the business of breaking down silos, almost everyone will be trying undermine you as soon as they think you're threatening them with any kind of oversight, regardless of how badly they know that they need process changes.

Anyway, the best devops people are usually excited to code themselves out of a job. To a large extent.. that's what has happened. We're out of the research phase of looking for approaches that work. For any specific problem in this domain we've mostly got tools that work well and scale well. The tools are documented, mature, and most even permit for a healthy choice amongst alternatives. The landscape of this tooling is generally hospitable, not what you'd call a desert or a jungle, and it's not as much of a moving target to learn the tech involved as it used to be.

Not saying every dev needs to be a Kubernetes admin.. but a dev refusing to learn anything about kubernetes in 2024 is starting to look more like a developer that doesn't know Linux command line basics. Beyond the basics, Platform teams are fine.. they are just the subset of people with previous DevOps titles that can actually write code, further weeding out the old-school DBAs / Sysadmins, bolstered by a few even stronger coders that are good with cloud APIs but don't understand ELBs / VPCs.

Re: A Eulogy for DevOps

#72

Post by mingus88 »

betaby wrote: post #63
29athrowaway wrote: post #55

Earlier quoted context omitted.

Sysadmins provisioned and managed version control systems for years. CVS, Subversion, etc.

RCS!

I introduced RCS to my sysadmin team in the mid 90s but again you always had those guys with god complexes who couldn’t be bothered to ‘ci -u’ or ‘co -l’ properly because that’s not how they do things. And if your entire team isn’t onboard then it’s worse than having no VCS at all

God riddance to those guys. They thrived in silos.

Re: A Eulogy for DevOps

#73

Post by sadops »

osigurdson wrote: post #64
chefandy wrote: post #49

Earlier quoted context omitted.

> There is no moral hazard, only an economic one. Er... No? If you take someone's money in exchange for goods and services, you have a moral duty to give them what you said you would. Not a broken version of it– what they bought. If you explicitly state they're getting an unstable product, then sure. If you actually do your best within reason and your service is broken, shit happens. Nobody is perfect, but you made a…

Is your argument than an amount of money approaching zero in the limit is morally distinct from zero - triggering a step change in behavior?

I think you know what they're arguing. It couldn't be clearer.

Re: A Eulogy for DevOps

#74

Post by sadops »

treis wrote: post #69
agentultra wrote: post #38

Didn't help that we had made these components and services into commodities. Developers and organizations came to expect them. Of course you use CI/CD pipelines to build and deploy your software. Of course you use orchestration and autoscaling groups. And so on. So that even if you're building small website for your local soccer club it's probably run through GHA on every change with a full red/green deploy process,…

This is one of those things that still makes me scratch my head. When I started programming my code ran on a 2-4 thread machine with a couple GB of ram because that was the size of a relatively affordable commodity server. Today my code runs on a 2-4 thread pod with a couple GB of ram because... reasons I guess. The industry has been given servers with 100x the resources and collectively said "naw I'm good". Can't wr…

[flagged]

Re: A Eulogy for DevOps

#75

Post by chefandy »

osigurdson wrote: post #64
chefandy wrote: post #49

Earlier quoted context omitted.

> There is no moral hazard, only an economic one. Er... No? If you take someone's money in exchange for goods and services, you have a moral duty to give them what you said you would. Not a broken version of it– what they bought. If you explicitly state they're getting an unstable product, then sure. If you actually do your best within reason and your service is broken, shit happens. Nobody is perfect, but you made a…

Is your argument than an amount of money approaching zero in the limit is morally distinct from zero - triggering a step change in behavior?

I should have known better then to take that bait. I'm not interested in pedantic philosophical debate about theoretical obligations skewed by imaginary prices that don't reflect real world business scenarios. In fact, I'm opting out of this entirely. Have a good night.

Re: A Eulogy for DevOps

#76

Post by sadops »

TranquilMarmot wrote: post #17
zer00eyz wrote: post #5

> Money was (effectively) free so it was better to increase speed regardless of monthly bills. Jesus this. No one knows where the money goes. If you can't tell me cost per customer, per user then your business is missing key metrics. > ... "discovered" that troubleshooting Kubernetes was a bit like Warhammer 40k Adeptus Mechanicus waving incense in front of machines they didn't understand in the hopes that it would m…

I _really_ miss having a dedicated QA team / process. I noticed that the role essentially disappeared a few years back, and now developers and users have to be the ones asking "is this working the way it should be?"

Pouring out for QA over here. My first gig ever, we had lovely QA people who spent all day just... using the application and trying to make it break. When it did, they'd fail tickets back to us, and we'd fix them. It worked so amazingly well. Now? Hurried, bored devs do it to get the next release out the door, and it shows.

Re: A Eulogy for DevOps

#77

Post by sadops »

nsxwolf wrote: post #25

I still don’t really know what DevOps is. I have noticed, however, that over the last 20 years more and more power and flexibility has been taken away from me. I used to have passwords for everything and could deploy things and get things done on a dime, now there are layers of bureaucracy and middle fingers everywhere I turn. Is that DevOps?

YAML over SSH, primarily.

Re: A Eulogy for DevOps

#78

Post by sadops »

giantg2 wrote: post #7
29athrowaway wrote: post #6

The problem is when hardened system administrators and DBAs were replaced by people who were certainly not worthy successors. As that transition took place, a lot of the added value was eliminated.

But who needs to know what happens behind the facade of the services? It does everything for us! I miss the days of having an expert sys admin and DBA to help with tough issues. Now we're all on our own with no training. Most of the good people got axed or thrown into other roles. Becoming good at something only to have it thrown away and undervalued pisses me off.

[flagged]

Re: A Eulogy for DevOps

#79

Post by aliasxneo »

betaby wrote: post #61
milkglass wrote: post #48

Earlier quoted context omitted.

Where's all the good operations people at nowadays? Have worked with numerous cloud native engineers that do not have good foundational knowledge.

> cloud native engineers That's the problem. Yes, I'm the old man yelling at cloud, but indeed 'kids this days' don't know Linux, they know how to provision things from Terraform. In fact it feels like logging in via ssh and checking process with with `strace` is a lost art. Checking PCAP? That's a black magic!

I think this comment is a bit unfair. A lot of work goes into not having to do those things. Good immutability often means less need for babying a specific server.

It’s been a long time since I’ve had to do those things, so yes it’s becoming a lost art to me. However, on the rare occasion I need this sort of insight I do fine with JIT research.

Re: A Eulogy for DevOps

#80

Post by eddythompson80 »

photonthug wrote: post #41
TranquilMarmot wrote: post #17

Earlier quoted context omitted.

I _really_ miss having a dedicated QA team / process. I noticed that the role essentially disappeared a few years back, and now developers and users have to be the ones asking "is this working the way it should be?"

This is under appreciated. What happens is that product managers are either crippled with the fallout from double duty, or, they go mad with power at the extra clout they are given to try to compensate for the nonsense position that orgs find themselves in. Both are ugly situations, and either way we lost important checks and balances. Putting anyone else in charge of quality turns into self reporting and always has…

Or what happened in my company where product managers were expected to take on a marketing role, and developers were the ones left with 3 roles or product management (usually left to the dev manager), development and QA on the individual developer. You’re left with product managers have no clue how the product works. They meet with 3-8 customers or other teams a day, and come back with a check-list of “must haves”. They have no idea how the existing product works, they just know that “customer is asking for X, what’s the timeframe for adding X?”. Then dev managers who have to take product management role, so they have no time for understanding how anything is actually built. Their time is spent defining timeframes, requirements, and expectations with other teams. “We trust our developers to do the right implementation”. Then developers who just get piecemeal requirements and are asked to implement it in the simplest fastest way. No time for a major redesign or refactoring of anything. Because from the PM prospective, there is a check-list of items we need and there are 2 unchecked boxes. From the dev manager prospective, we have X and Y, so having XY makes sense. Then from the developer prospective, just duct-tape them together instead of actually building Z which is what makes sense.
Post reply on HN