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

111–120 of 175 posts

Re: A Eulogy for DevOps

#111

Post by signal11 »

wokwokwok wrote: post #109
smusamashah wrote: post #60

Earlier quoted context omitted.

I bumped into a DevOps job at Teradata, did it for two years, then left for where I belong, in gaming as a backend developer. It was a corporate with good pays and perks including international travel etc. Some friends are still there doing DevOps very happily. Talking to them it never feels a like a dying field. I hated my DevOps role so pardon me for only reading the headings of the article, but talking about it in…

The deep deep irony of hiring someone specifically to do "devops". That's not devops. Devops is when you have developers who are empowered. When you hire someone specifically to do devops you are hiring an ops team and calling it devops. So, yeah. That still happens, sure. However, I do think it's changing these days: linkedin > connections -> control-F -> 'devops' => 0 hits "Site Reliability Engineer" -> 10 hits I t…

This. I see ads for DevOps roles as a signal that “this org doesn’t get it”.

DevOps is about people and culture. Your teams embrace automation, fail fast, lean — all the good stuff. DevOps is about concrete business outcomes. Not Ansible or bazel.

> hiring devops means you never understood, even vaguely, what devops was; you're just using a buzz word in your job ad.

Yes!

Re: A Eulogy for DevOps

#112

Post by zer00eyz »

whoknowsidont wrote: post #107
zer00eyz wrote: post #43

Earlier quoted context omitted.

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…

>The whole ecosystem around it is an example of Conways law This is such an inaccurate take. >we need to stop using containers as bags Containers and container orchestration are a NEEDED and REQUIRED piece of the technology stack in the current reality. That doesn't mean people need to be ignorant of the details that make them work. As someone who's been around for a while we are in a better place than when we had "d…

> Containers and container orchestration are a NEEDED and REQUIRED piece of the technology stack in the current reality.

If you're deploying NODEjs apps to the cloud, they sure are.

> if you're going to have teams of people pretend to know what they're doing wrapping it in a standard "bag" sure does make it a hell of a lot fucking easier to unfuck when things go wrong.

No one looks in the bag, they just roll back, the bag is opaque, the bag breeds more bags, less trnasparency and higher costs.

Step back and read what you wrote, if you described any other relationship in your life in these terms, your friends would be having an intervention. The codependent circle jerk has enabled so much bad behavior. The tooling you're advocating for is an enabler.

I want App Store like software roll outs. The infrastructure we have is kind of like that, if you don't look too close. We need to start doing the hard work to make it not suck. We need to stop pretending that this is a good place and put in the work to make it better.

Otherwise its never going to get untucked...

Re: A Eulogy for DevOps

#113

Post by zer00eyz »

osigurdson wrote: post #42
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…

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

> shell into containers

The problem here is that once your in and need tooling what do you do? Your likely going to have to re-build the whole container with that tooling on board (if its even possible)...

Containers aren't problematic in themselves. There are reasons to use them. Ruby, php, JS python (fucking venvs) have this habit of contaminating a system. Containers are a great way of... containing that shit.

But the moment I'm giving you a single file binary.. why in the name of all that is holy are you putting it in a container? If it's untrusted software then there is a good reason but then why are you running it at all?

And that's the thing. Depending on what I ask you to do there are places where your not going to say "let me put this in a container" ... Most of that is "good software" and "performant" ... Its a statement about everything that comes in that "container"

Re: A Eulogy for DevOps

#114

Post by udev4096 »

osigurdson wrote: post #37

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

Whoever has worked with bash scripts would know that relying on a bunch of bash scripts for your infrastructure is extremely naive. At the end of the day, Kubernetes is just a tool with complexities in place for companies with larger workloads

Re: A Eulogy for DevOps

#115

Post by udev4096 »

sadops wrote: post #68
betaby wrote: post #61

Earlier quoted context omitted.

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

This is the elephant in the room: all "new" technology isn't fundamentally new. Terraform is just curl with state management for lots of different websites, Andible is just a YAML to Bash converter, and so on. If you have good fundamentals, not only are these things easy, they're also incredibly frustrating, because you can easily see their limitations. You can always tell how experienced someone is by how well they…

Ansible is a lot more than just "YAML to Bash". For instance, Bash scripts are not idempotent. Ansible playbooks are. Sure, you can hack together a way to ssh and run commands very easily but it will break at some point

Re: A Eulogy for DevOps

#118

Post by Sn0wCoder »

Sn0wCoder wrote: post #90
fragmede wrote: post #85

Earlier quoted context omitted.

that doesn't work at scale though. the difference between dev, staging, and prod when there's a handful of services is fine. when there's 300 of them, and 200 of them are broken in the dev environment at any given time, that means you can't actually use the dev environment to do development in because the 300 other teams are also trying to do development in that same environment so their stuff is just as broken as yo…

Development should never be broken, ever. Ready to ship and broken are two different things. By ready to ship it more like v2 has 8 total new endpoints and only 2 are ready, then 4, then 6, then 8. When the tests fail, or the code quality goes down, the deployment fails. I would rather have DEV broken than PROD. Not sure how going directly to PROD would make anything better in this scenario. That is what Integration…

Just want to add that these are all good points and good discussion. Ultimately, I think we agree that DeOps is needed no matter how it’s used. The details of how exactly it’s used per product, per team, per organization is always ‘it depends’. Some of us need to jump through more hoops and there is no way any of our products would be updated in production multiple times per day much less multiple times per month unless it was a hot fix of a critical bug. CI/CD is something to strive for as if you can release to develop multiple times per day it’s only the surrounding process that prevents you from releasing to production multiple times per day.

Re: A Eulogy for DevOps

#119

Post by hparadiz »

signal11 wrote: post #111
wokwokwok wrote: post #109

Earlier quoted context omitted.

The deep deep irony of hiring someone specifically to do "devops". That's not devops. Devops is when you have developers who are empowered. When you hire someone specifically to do devops you are hiring an ops team and calling it devops. So, yeah. That still happens, sure. However, I do think it's changing these days: linkedin > connections -> control-F -> 'devops' => 0 hits "Site Reliability Engineer" -> 10 hits I t…

This. I see ads for DevOps roles as a signal that “this org doesn’t get it”. DevOps is about people and culture. Your teams embrace automation, fail fast, lean — all the good stuff. DevOps is about concrete business outcomes. Not Ansible or bazel. > hiring devops means you never understood, even vaguely, what devops was; you're just using a buzz word in your job ad. Yes!

I honestly don't get this thread and the complaining. Yes, I was one of those empowered engineers at an org that did ALL of the DevOps. But do ya'll seriously think you don't sometimes need people who do ONLY DevOps? Cause I can tell you there are absolutely orgs that deploy dozens, if not hundreds of servers sometimes by region and in those cases you absolutely do need full time DevOps engineers to tune, configure, and deploy these fleets. And yea it's a full time job just to do that.

Re: A Eulogy for DevOps

#120

Post by whoknowsidont »

zer00eyz wrote: post #112
whoknowsidont wrote: post #107

Earlier quoted context omitted.

>The whole ecosystem around it is an example of Conways law This is such an inaccurate take. >we need to stop using containers as bags Containers and container orchestration are a NEEDED and REQUIRED piece of the technology stack in the current reality. That doesn't mean people need to be ignorant of the details that make them work. As someone who's been around for a while we are in a better place than when we had "d…

> Containers and container orchestration are a NEEDED and REQUIRED piece of the technology stack in the current reality. If you're deploying NODEjs apps to the cloud, they sure are. > if you're going to have teams of people pretend to know what they're doing wrapping it in a standard "bag" sure does make it a hell of a lot fucking easier to unfuck when things go wrong. No one looks in the bag, they just roll back, th…

>If you're deploying NODEjs apps to the cloud, they sure are.

I don't use nodejs.

>No one looks in the bag

I sure have. Plenty of times.

>if you described any other relationship in your life in these terms, your friends would be having an intervention.

For having a standard tool that you know how to use? That doesn't seem correct and it certainly isn't proportional.

>I want App Store like software roll outs.

Okay it sounds like you want K8's.

Post reply on HN