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

21–30 of 175 posts

Re: A Eulogy for DevOps

#21

Post by curiousdeadcat »

john-radio wrote: post #18
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 so glad you quoted that because I missed it skimming the article and it's the funniest shit I've ever heard.

K8s grinds my gears, and yet, I'd rather debug it than, or beholden to, AWS or Azure, every day of the week

Re: A Eulogy for DevOps

#22

Post by [deleted] »

pas wrote: post #4
andrewstuart wrote: post #2

Am I correct in understanding that microservices and DevOps are closely related - in that microservices trade code base complexity for operations complexity?

I would say they are both the fruit of the "ownership tree". Both are solutions to big but specific problems. (DevOps was a push against crazy corporate IT, where developers handed over the sacred tomes of operational manual and the blessed JAR/WAR files and IT took over from there. And operations was on-call, and ... had absolutely zero fucking idea what to do, the manuals were fake, and they had no expertise, and t…

[deleted]

Re: A Eulogy for DevOps

#23

Post by inopinatus »

paulsmith wrote: post #20
andrewstuart wrote: post #2

Am I correct in understanding that microservices and DevOps are closely related - in that microservices trade code base complexity for operations complexity?

DevOps predated microservices by a good bit. And DevOps was meant to reduce operational complexity, because the people who best knew how to run the software were the ones who made it. (DevOps also predated commoditization of the infra layer, we didn't know about Docker or k8s yet.) And they could use the direct experiential feedback loop of driving the car they had built to plow understanding right back into the next…

Most institutions failed to understand that devops is a practice of silo busting, not a team or a job title. The most devopsy thing you can do is treat IT service development and ownership like a product instead of a project. All you really have to do, though, is sit the developers next to the ops folks and let the law of proximate communication do the rest.

Institutions and institutional corporations generally can’t make the switch in mindset to multidisciplinary service teams, and established project managers will even fight it tooth and nail since it looks like a threat to their jobs.

Microservices are orthogonal. Architecturally they are just SOA, now with json/grpc instead of wsdl et al. Operationally and strategically they are slightly a better fit for service teams, but only at scale. Small and medium enterprises will experience inefficiency instead.

Conway’s Law is super applicable to understanding these dynamics.

Re: A Eulogy for DevOps

#25

Post by nsxwolf »

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?

Re: A Eulogy for DevOps

#26

Post by adolph »

Spartan-S63 wrote: post #16
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…

> > 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. This is where something like FinOps comes into play as a framework to adapt to your needs.

Yes, some K8s operators to cost your deployments so you can auto scale based on ROI of a microservice instead of raw utilization. No point in spending on five nines if nobody will even pay for two.

It’s all straight out of “programmers are also human” https://youtu.be/aWfYxg-Ypm4

Re: A Eulogy for DevOps

#27

Post by lazyant »

This was a bit of a straw man argument against DevOps and normal CI/CD that describes as only safety net the PR review and forgets about automated (unit, integration and end-to-end) testing and other de-risking activities like canary releases (funny enough, this is what Facebook heavily relies on so devs can push to prod on their first day).

Re: A Eulogy for DevOps

#28

Post by 8organicbits »

austinshea wrote: post #14

This is entirely predicated on the issues this person experienced. Irrespective of whether or not devops teams end up with solutions that look like this, none of them are meant to. My first experiences had to do with the ability to add new services, monolith or not, and have their infrastructure be created/modified/removed in a environment/region in-specific way, and to be able to safely allow developers to self-serv…

Agreed, standardization has been hugely helpful.

From the article:

> adopt much more simple and easy-to-troubleshoot workflows like "a bash script that pulls a new container".

This style of thinking let's developers learn every nitty gritty pain of why we have frameworks. I see the same challenge with static site generators, they are all kinda annoying so people write their own, but then theirs is even worse.

Re: A Eulogy for DevOps

#29

Post by Sn0wCoder »

wokwokwok wrote: post #19

There’s so much truth in this. It really cuts to the heart of it when you looking at the “devops cycle” diagram with “build, test, deploy” …and yeah, those other ones… I remember being in a meeting where our engineering lead was explaining our “devops transformation strategy”. From memory that diagram turned up in the slides with a circle on “deploy”; the operational goal was “deploy multiple times a day”. It was abo…

DevOps and releasing multiple times per day does not always mean to PROD and in most industries that is impossible. Continuous Integration and Continuous Deployment should and do mean to the development branch and container. Locally I can write code and skip all the tests, skip the linter, skip prettier, etc.….

When I do a commit prettier is run. When I PR into develop other dev’s review the code. When its approved and completed a build is run (including all tests and sent to Veracode and SonarQube for analysis). The build is deployed to the development container where the developers can smoke test and then when SQA is ready promote to Integration for real testing. Fail fast! If the tests fail, we can fix them. If code quality goes down, we can fail the gate === no deployment. Without DevOps and CI/CD these steps get skipped.

Not sure where the idea that software is released to production multiple times per ever came from. Yes, the develop branch should in theory be ready to be promoted at any time but we know that is not reality.

Re: A Eulogy for DevOps

#30

Post by cglendenning »

People who understand and can articulate enduring principles without going mad in a sea of bad ideas will perpetually increase their own value in an organization. Thank you for this article. I don't share so much of the cynical view of leadership intent, but I can understand it.
Post reply on HN