DevOps Isn't Dead, but It's Not in Great Health Either
thenewstack.io
DevOps Isn't Dead, but It's Not in Great Health Either
1–10 of 74 posts
Re: DevOps Isn't Dead, but It's Not in Great Health Either
#2DevOps like Agile was a beautiful idea with a coherent underlying well reasoned philosophy.
DevOps like Agile was then hacked to pieces and had its corpse paraded around by sleazy consultants and idiotic management that was told "you can save all this money on all your infrastructure people by making your developers do all the ops stuff to." And who doesn't like saving money on those useless crusty old system administrators that don't seem to do anything except whine for "more disk space" if they were so smart they would've prevented that outage la da t week where the logging volume filled up.
Finally the toolmakers sold the idea that DevOps was something you could buy. Just like the vendors convinced management that buy purchasing Jira you were now agile, now if you have a CI/CD pipeline you are now doing DevOps. But you still can't release without getting approval from the release committee and you can't actually provision a new host in the cloud until you have filled out the requsite approval forms, but key for some reason we uprooted our monolith and threw it on kubenetes so we are doing DevOps.
It really feels like relieving the Agile cycle all over again in every detail. Just wish I could figure out the next big fad so I could get in on this money printer.
PS. If you use the term DevSecOps or DevSecFinOps unironiclly your living proof the Dunning-Kruger effect.
Re: DevOps Isn't Dead, but It's Not in Great Health Either
#3I don't necessarily think this is a bad thing.
I "enjoy" doing my own ops part of the job because it often feels like I have fewer roadblocks in my way. I build my stuff (or fix my stuff), test it, build some deployable artifact, and deploy it. I do it all on my own schedule, immediately when I'm ready to do each step, and I don't have to wait on someone else.
But if I'm being honest, I have spent so so so many hours dealing with "ops bullshit", that I probably would have been more productive overall (perhaps worse latency, but better throughput) if I could have just focused on the build/fix and test parts, and kicked the final result over to another team to deal with deployment concerns.
I'm still not sure which is better. Maybe neither is objectively better, and it depends on the person and organization. Maybe have separate teams, but make your devs do a tour of duty through the ops team every now and then so they understand why the ops people get mad at them from time to time. And vice versa.
Anyway, I don't buy the CYA/hand-wavy reasons in the article guessing why DevOps is supposedly dying. I suspect it's for the same reason Agile turned out to be a drag on so many developers: people cargo cult and don't really understand why they're doing a particular thing, so they never adapt it properly to their environment.
So the managers bring in consultants, and the consultants just roll out their cookie cutter solution, with their favorite issue tracker, CI/CD product, deployment system, etc., without really understanding the org's needs.
Then the managers get upset, and we get articles like this.
Re: DevOps Isn't Dead, but It's Not in Great Health Either
#4I don't necessarily think this is a bad thing. I "enjoy" doing my own ops part of the job because it often feels like I have fewer roadblocks in my way. I build my stuff (or fix my stuff), test it, build some deployable artifact, and deploy it. I do it all on my own schedule, immediately when I'm ready to do each step, and I don't have to wait on someone else. But if I'm being honest, I have spent so so so many hours…
Exactly, dunno what to call it ... but every new concept starts out good, gets crazier and crazier and sometimes it may become good again, but most of the time it just devolves into more crazy.
In one of the orgs I worked, ther was a team which worked on the basic devops framework which the application teams could use to then configure their resources. It was a very sane approach.
Re: DevOps Isn't Dead, but It's Not in Great Health Either
#5Performance in the report is defined by how fast you can make a change to production, and how fast you can restore service.
That’s fine I guess.
What’s not taken into account is the time wasted on incidental complexity with devops tools.
For example a highly competent engineer I know is burning hours trying to get ssl working on k8s/gcp with a specific configuration.
Conceptually ssl is all straightforward, but there’s some arcane knowledge that’s been designed into k8s and gcp. Because they were designed for way more complex use cases… but they’ve also pushed out simpler tools.
Re: DevOps Isn't Dead, but It's Not in Great Health Either
#6I like DevOps, I don't like being on call 24x7 so I tell my clients I am a software developer not an ops. DevOps was sold as a way to avoid dev and ops teams blaming each other for not shipping software. It was at the time true that devs did not understand hardware and networking and ops did not particularly understand software. We got nice things like Docker and k8s, but the core issues have not gone away, devs don't understand hardware and networking and ops are an almost extinct species. We are re-learning the hard way that certain performance problems are not solved by throwing more hardware at them and that devs will always write Helm charts for convenience and not security. We are also learning that the complexity of networking and backed designs has not gone away we just got more modern tools to describe it. One other unintended negative consequence of misunderstanding DevOps is the proliferation of "full-stack engineers", which is basically an ops, a DBA, a secops, a backend dev, a frontend dev, and a website designer rolled into one. What we have today is a situation pretty much the same as it was before the arrival of DevOps... devs thinking ops are useless, ops thinking dev are no good and ... both thinking the others have no sense of style.
Re: DevOps Isn't Dead, but It's Not in Great Health Either
#7DevOps like Agile was a beautiful idea with a coherent underlying well reasoned philosophy. DevOps like Agile was then hacked to pieces and had its corpse paraded around by sleazy consultants and idiotic management that was told "you can save all this money on all your infrastructure people by making your developers do all the ops stuff to." And who doesn't like saving money on those useless crusty old system adminis…
To me, agile is simply
People over process
Results over bluster
Flexibility over rigidity
Re: DevOps Isn't Dead, but It's Not in Great Health Either
#8DevOps like Agile was a beautiful idea with a coherent underlying well reasoned philosophy. DevOps like Agile was then hacked to pieces and had its corpse paraded around by sleazy consultants and idiotic management that was told "you can save all this money on all your infrastructure people by making your developers do all the ops stuff to." And who doesn't like saving money on those useless crusty old system adminis…
To me, agile is simply People over process Results over bluster Flexibility over rigidity
Until that director comes
Expecting results
Yesterday
Re: DevOps Isn't Dead, but It's Not in Great Health Either
#9Three days ago: https://news.ycombinator.com/item?id=40860135
Re: DevOps Isn't Dead, but It's Not in Great Health Either
#10DevOps like Agile was a beautiful idea with a coherent underlying well reasoned philosophy. DevOps like Agile was then hacked to pieces and had its corpse paraded around by sleazy consultants and idiotic management that was told "you can save all this money on all your infrastructure people by making your developers do all the ops stuff to." And who doesn't like saving money on those useless crusty old system adminis…
To me, agile is simply People over process Results over bluster Flexibility over rigidity
Management just slaps agile onto everything nowadays. No time given for coming up with better solution, reducing tech debt. Most companies devolving into feature factories now. I call this methodology FRAGILE®