Live data from Hacker News

A Eulogy for DevOps

matduggan.com

61–70 of 175 posts

Re: A Eulogy for DevOps

#61

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…

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!

Re: A Eulogy for DevOps

#62

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

It's basically a prototype that industry ran away with. It leaks implementation details everywhere and pushes way too many config options up to the developer. Because industry ran away with it before it could be good, it takes projects like Cilium to push it in the right direction, but those take forever to get adopted and are really hard because they don't live in the product itself. You'd need like 10 more Ciliums…

Can you clarify what you mean by "leaks implementation details everywhere"?

I like to think of kubernetes as a big orchestration platform that you can choose to use what you need. If an ingress and pods work then use that, otherwise extend an throw an operator up for what you need (it likely already exists).

Cilium for instance is great for that, so is Istio and the like. They aren't hard you just have to understand networking... which is nearly the same energy of running it on another orchestration tool or raw on a network device.

Re: A Eulogy for DevOps

#63

Earlier quoted context omitted.

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…

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

RCS!

Re: A Eulogy for DevOps

#64

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

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

Re: A Eulogy for DevOps

#65

Earlier quoted context omitted.

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 a…

> Not sure where the idea that software is released to production multiple times per ever came from. UX-focused development. Your concern is mainly about user journeys, acquisition tunnels, etc. So you rely on user feedback a lot. So you ship, A/B test, iterate. Also, if your service consists of lots of microservices, you don’t want to wait to ship them all at the same time. The most fitting example to both is probab…

Fair enough.

Guess that is why Netfix is so Glitchy every other day j/k.

I should have kept that last sentence out but I will not edit it now as I asked….

Re: A Eulogy for DevOps

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

Me too. Oh man, me too. Often times, the good QA people/teams were the ones who knew how a feature fully worked. It’s limitations, extensibility, interoperability with other features, etc. In the beginning of the transition/disappearnce of QA developers were told they needed to be their own QA. And this made some sense assuming the dev would be given 2x the time for each feature. But that expectation quickly changed to build an MVP, give a demo, ship it to “get feedback from users”.

Re: A Eulogy for DevOps

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

That’s compliance, infosec, and arguably, just table stakes for a reasonably mature org. Sure it’s annoying sometimes but unless you enjoy the idea of randos with access to your own complete digital footprint, then everyone ought to see the wisdom in the idea of “robots only, no humans in prod”

Yeah I agree, it's unfortunate that security compliance is often just making things as hard as possible in most organizations. Often times devops get to be the face of that and trust me.. they sure as hell don't want to have to hold hands even more.

Re: A Eulogy for DevOps

#68
post #61

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!

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 know what a given tool is actually doing under the hood. People who exhibit shock and awe will just mess up your codebase, because they have no clue how the machine actually works.

No, I want to hire the grumpy, cynical greybeards, because they know their fundamentals, and they're immune to shiny bullshit.

There's no substitute for skill and experience, despite what the modern tech discourse says. "Anyone can program!" And yet, we have threads like this, where we find out, SHOCKER, that the best codebases are the ones maintained by like... four senior developers, half of whom contributed to several Internet RFCs, and half of whom used to work at Bell Labs.

I feel like we are through the looking glass.

Re: A Eulogy for DevOps

#69

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 wrap my head around it.

Re: A Eulogy for DevOps

#70

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

It's basically a prototype that industry ran away with. It leaks implementation details everywhere and pushes way too many config options up to the developer. Because industry ran away with it before it could be good, it takes projects like Cilium to push it in the right direction, but those take forever to get adopted and are really hard because they don't live in the product itself. You'd need like 10 more Ciliums…

Kubernetes is just a poor Linux clone with extra steps. Seriously, it has all the basic parts of an OS, just half-assed: the scheduler, the networking, the state management. We already had way better operating systems that can, you know, schedule workloads and talk to the network, and it didn't require gigabytes of YAML and string templating to make it happen.
Post reply on HN