Live data from Hacker News

A Eulogy for DevOps

matduggan.com

91–100 of 175 posts

Re: A Eulogy for DevOps

#91

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

Agreed. If we didn’t use kubernetes, we’d have to reimplement a bunch of its features. Back when we were getting started I tried docker swarm because it was supposed to be simpler, but I had weird issues with its networking. The best part is multiple environments. I can run our full stack on my laptop with k3s and one call to make. We use the same yaml (with kustomize) for all three cloud environments. It feels prett…

The argument against Kubernetes is not that you should go backwards from it, but that there is a huge need for something better than it. Many big tech companies have platforms that are better than it which aren’t properly (if at all) externally productized.

And the fact that many medium companies have “platform teams” configuring Kubernetes and gluing together basically the same set of tools (source, build, test, release, ops, obs) together in basically the same way is a huge smell that something better is needed. Basically, doing things the right way is actually a big operational/engineering/monetary burden for most companies that just want to write applications. And K8s is a big part of that

Re: A Eulogy for DevOps

#92

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…

> couldn’t handle a reality where they couldn’t name all their systems with cute Dr Who hostnames

Worked with so many of these guys. They really are the worst.

Re: A Eulogy for DevOps

#93
post #73

Earlier quoted context omitted.

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

I think you know what they're arguing. It couldn't be clearer.

I'd like them to be clear about their own thinking. Something occurs in their mind once money is exchanged. If time is exchanged (i.e. advertising), on the other hand, no such pact is created. Why? Isn't money essentially a proxy for time?

Re: A Eulogy for DevOps

#94

Earlier quoted context omitted.

Agreed. If we didn’t use kubernetes, we’d have to reimplement a bunch of its features. Back when we were getting started I tried docker swarm because it was supposed to be simpler, but I had weird issues with its networking. The best part is multiple environments. I can run our full stack on my laptop with k3s and one call to make. We use the same yaml (with kustomize) for all three cloud environments. It feels prett…

The argument against Kubernetes is not that you should go backwards from it, but that there is a huge need for something better than it. Many big tech companies have platforms that are better than it which aren’t properly (if at all) externally productized. And the fact that many medium companies have “platform teams” configuring Kubernetes and gluing together basically the same set of tools (source, build, test, rel…

Big tech companies are willing to invest in those platforms and mold them to work like they want to work. Few other companies do so and Kubernetes becomes the way to get big tech like platform.

I do agree it could be better but it's Un opinioned nature also let's these companies shape it in a way that matches where they are. Also, probably biggest issues with it only come up if you are not in managed Kubernetes which many are.

Re: A Eulogy for DevOps

#95

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…

Kubernetes is actually extremely popular all around the world. Chickfila if I recall correctly deploy it in every single store! A lot of big dinosaur corporations are implementing it actively. Unfortunately VMs or Kubernetes or whatever tooling is still going to suck if you have shitty people using them.

VMs are going to suck if you use VMWare and they hike the price four fold.

Re: A Eulogy for DevOps

#96
I have long felt that DevOps was always a philosophy, not a methodology. It simply meant folding all that operations stuff into the SDLC. It was always about making Ops part of Dev, not the other way around, and especially not as a standalone discipline. The cloud made this a lot easier, as everything could be done programmatically, but the philosophy held true long before that.

It doesn't mean CI/CD pipelines, Terraform, or YAML. Those are all incidental.

The moment specialised "DevOps" teams started springing up it was all over. We just reinvented the sysadmin.

Re: A Eulogy for DevOps

#97
post #73

Earlier quoted context omitted.

I think you know what they're arguing. It couldn't be clearer.

I'd like them to be clear about their own thinking. Something occurs in their mind once money is exchanged. If time is exchanged (i.e. advertising), on the other hand, no such pact is created. Why? Isn't money essentially a proxy for time?

Absolutely not. Quit the bad faith arguments please

Re: A Eulogy for DevOps

#98

Earlier quoted context omitted.

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…

You shouldn’t have to think about all the implementation details of your deployment target. There shouldn’t be platform engineers or Kubernetes experts. Nobody should be writing YAML, or getting paid to set up Istio. Nobody should have to learn the Kubernetes architecture or know about the kubelet or EBPF. The tools should be simple enough with good defaults that application developers just click a button and have th…

Ops here, In a simple Kubernetes environment, you don't have to know networking. However, few environments are simple and abstracting X away becomes extremely difficult job once business requirements collide with abstraction.

Obstacle is big most of time because most applications are not easy to run. Most DevOps mostly came around because Devs flinging balls of mud over the wall and landing on the Ops side with a splat and then screaming when we can't build nets to catch the mud ball and Ops is covered with mud. Sure it failed just like DevSecOps fails because most of time, Devs don't care about anything other than closing Jira tickets and going home.

Re: A Eulogy for DevOps

#99
post #63

Earlier quoted context omitted.

RCS!

I introduced RCS to my sysadmin team in the mid 90s but again you always had those guys with god complexes who couldn’t be bothered to ‘ci -u’ or ‘co -l’ properly because that’s not how they do things. And if your entire team isn’t onboard then it’s worse than having no VCS at all God riddance to those guys. They thrived in silos.

Well, some people are not agreeable, do not want to be seen taking guidance from others.

They are not worried about understanding what they do, or improving their practices, they are worried about status and how others perceive them.

Those people may be able to protect their status in the short term, maybe even bluff and be promoted. But they will never truly understand what's going on.

Re: A Eulogy for DevOps

#100

Earlier quoted context omitted.

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…

You shouldn’t have to think about all the implementation details of your deployment target. There shouldn’t be platform engineers or Kubernetes experts. Nobody should be writing YAML, or getting paid to set up Istio. Nobody should have to learn the Kubernetes architecture or know about the kubelet or EBPF. The tools should be simple enough with good defaults that application developers just click a button and have th…

You don't need any of that, EKS works out of the box with Fargate.

But companies don't want that, they want to support EKS and data centers, which means supporting the "implementation" side of all of the interfaces, which means getting down into the details.

The real problem is that every platform team, deep down, wants to rewrite EKS and they often do, which I would describe as "a giant money pit".

Post reply on HN