Live data from Hacker News

A Eulogy for DevOps

matduggan.com

41–50 of 175 posts

Re: A Eulogy for DevOps

#41
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?"

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 a conflict of interest

Re: A Eulogy for DevOps

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

>> "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 make the problem go away

I'm not familiar with the reference but logs, events and metrics seem pretty useful. Port forward, shell into containers, view logs, etc. I don't see what is so bad about it.

Re: A Eulogy for DevOps

#43

>> abandon technology like Kubernetes I think a lot of Kubernetes hate is misplaced. It is a great piece of software engineering, well supported and runs everywhere. You certainly don't always need it but don't create a bunch of random bash scripts running all of the place instead of learning how to use it.

Its not.

The whole ecosystem around it is an example of Conways law and and a Google product.

None of the people using it are google.

Google, also, runs its own hardware.

Shockingly it is a great product if you rent hardware, autoscaling is autospending. No one knows what a feature costs any more because its all just a big bucket your pouring money into for amazon to have 30 percent margin on.

We need operations people again, we need to stop using containers as bags for shitty "software" ... Do actual engineering.

Re: A Eulogy for DevOps

#44
One item the DevOps mindset missed was reproducibility. Fast feedback loops in spirit tell to have a way to know what’s wrong but it doesn’t tell how to reproduce it as you have layers and layers where your code is run. So, you are in a spot of I kinda know what’s going on but I have no way to reproduce it because:

- the application has hardcoded paths.

- the service discovery isn’t dynamic

- the branching strategy doesn’t account for edge cases.

- the build process doesn’t account for edge cases.

- and many other things that are related to bad practices.

I recall an old boss saying he wanted stable dev environments which sounded an oximoron. I’ve always aimed to have an environment where I can reproduce a desired behavior wether is a faulty or not.

Re: A Eulogy for DevOps

#45
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?

DevOps, in my experience, has often been unfortunately misused to mean "no ops": developers are doing operations, and there is no dedicated ops staff. For some engineers, this works. For others, they are out of their element and it leads to outages and chaos.

Re: A Eulogy for DevOps

#46

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.

I don’t know. As someone who has tried to introduce the simple concept of version control to various sysadmin orgs over the years, I am fine with many of those types of sysadmins going away

A lot of those guys just couldn’t handle a reality where they couldn’t name all their systems with cute Dr Who hostnames and do all their work as local root with riced out bash prompts

Devops at least forced them to the same table with the dev org, and if they ended up getting replaced in the transition then I shed zero tears

Re: A Eulogy for DevOps

#48

>> abandon technology like Kubernetes I think a lot of Kubernetes hate is misplaced. It is a great piece of software engineering, well supported and runs everywhere. You certainly don't always need it but don't create a bunch of random bash scripts running all of the place instead of learning how to use it.

Its not. The whole ecosystem around it is an example of Conways law and and a Google product. None of the people using it are google. Google, also, runs its own hardware. Shockingly it is a great product if you rent hardware, autoscaling is autospending. No one knows what a feature costs any more because its all just a big bucket your pouring money into for amazon to have 30 percent margin on. We need operations peop…

Where's all the good operations people at nowadays?

Have worked with numerous cloud native engineers that do not have good foundational knowledge.

Re: A Eulogy for DevOps

#49

>> The User is the Tester If you can afford to make the user the tester, you should. There is no moral hazard, only an economic one. If you have 5 million customers paying $1 / year, make the user do the testing via canary deployments, metrics, etc. If you have 5 customers each paying $1M / year, be sure to test it yourself. The problem seems to be that people forget which regime they are operating in.

> 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 good faith effort to deliver on your promise. But if you don't, and deliberately don't bother checking if it actually works while happily pocketing people's cash, that's unambiguously negligent. Ripping off small groups of customers is no morally different than ripping off all of your customers— it's the same immorality at a smaller scale so you're more likely to get away with it.

Re: A Eulogy for DevOps

#50

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.

I don’t know. As someone who has tried to introduce the simple concept of version control to various sysadmin orgs over the years, I am fine with many of those types of sysadmins going away A lot of those guys just couldn’t handle a reality where they couldn’t name all their systems with cute Dr Who hostnames and do all their work as local root with riced out bash prompts Devops at least forced them to the same table…

[deleted]
Post reply on HN