Live data from Hacker News

I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

blog.stackademic.com

201–210 of 216 posts

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#201
post #83

Why exactly did they have 47 clusters? One thing I noticed (maybe because I’m not at that scale) is that companies are running 1+ clusters per application. Isn’t the point of kubernetes that you can run your entire infra in a single cluster, and at most you’d need a second cluster for redundancy, and you can spread nodes across regions and AZs and even clouds? I think the bottleneck is networking and how much crossta…

We have 1 cluster per region (3 regions: Asia, US, EU), multiplied by redundancy clusters = 6 clusters. Then we have test environments, around 20 of them: 20 clusters. Then there are 10s of clusters installed on customers' infra. So 47 clusters isn't really a huge/strange number.

Why 20 test clusters? Do you have more developers than users?

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#202
Sensible. Kubernetes is an anti-pattern, along with containerized production applications in general.

-replicates OS services poorly

-OS is likely running on a hypervisor divvying up hardware resources into VPS's

-wastes ram and cpu cycles

-forces kubectl onto everything

-destroys integrity of kernel networking basic principles

-takes advantage of developer ignorance of OS and enhances it

I get it, it's a handy hack, for non production services or oneoff installs, but then its basically just a glorified VM

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#203
post #47

> DevOps Team Is Happier Than Ever Or course they are. The original value proposition of cloud providers managing your infra (and moreso with k8s) was that you could fire your ops team (now called "DevOps" because the whole idea didn't pan out) and the developers could manage their services directly. In any case, your DevOps team has job security now.

It doesn't take any more competent people to self-host a modern stack, than it does to babysit how a company uses something like Azure. The original value proposition is false, and more and more are realising this.

Hammer meet nail. I currently work in a more traditional "ops" team with our cloud infrastructure dictated by development (through contract hires at first, and now a new internal DevOps team). It's mind boggling how poorly they run things. It goes so deep it's almost issues at product design stage. There's now a big project to move the responsibility back into our team because it's not fit for purpose.

I think an operations background gives you a strong ability to smell nonsense and insecurity. The DevOps team seems to be people who want to be 'developers' rather than people who care about 'ops'. Yaml slinging without thinking about what the yaml actually means.

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#204

Earlier quoted context omitted.

My personal takeaway, when it fails and you can't blame anyone for any reason, blame a tool. You'll get the whole team helping you when replacing the tool and setting up a better solution. If you blame anyone, people will start to be extra cautious and won't take any initiative. But don't overuse it, if you always blame the tool, you'll end up like my ex colleague "Steve" where every failure was Microsoft's fault.

Your ex-colleague may not be factually correct, but I agree with him in spirit.

If you use powershell, what's your reaction when you delete some stuff by using the "-Force" parameter and that it's deleted ?

Steve usually said that Microsoft should ask for a confirmation before deleting anything, even with the "-Force" parameter.

It was Microsoft's fault when the whole test environment, that he spent two days setting up, was deleted with the "-Force" parameter. He said something along the lines of "Microsoft shouldn't let me do this".

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#205
post #17

Oh boy. Please, please stop using Medium for anything. I have lost count of how many potentially interesting or informative articles are published behind the Medium sign-in wall. At least for me, if you aren't publishing blog articles in public then what's the point of me trying to read them.

I often see articles posted simultaneously to Medium and the author's own site. I imagine it helps with visibility.

It would be nice if there was a common practice of including a link to the alternative version as the first line of a Medium article.

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#206

Why exactly did they have 47 clusters? One thing I noticed (maybe because I’m not at that scale) is that companies are running 1+ clusters per application. Isn’t the point of kubernetes that you can run your entire infra in a single cluster, and at most you’d need a second cluster for redundancy, and you can spread nodes across regions and AZs and even clouds? I think the bottleneck is networking and how much crossta…

It's just a matter of time before someone releases an orchestration layer for k8s clusters so the absurd Rube Goldberg machine that is modern devops stacks can grow even more complex.

This has already happened. There are orgs managing hundreds to thousands of k8s clusters.

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#207
post #144
post #58

So many astonishing things were done ... > As the number of microservices grew, each service often got its own dedicated cluster. Wow. Just wow.

That's not a microservice; that's a macroservice.

Distributed cloud-native monolith?

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#208

If you have 200 YAML files for a single service and 46 clusters I think you're using k8s wrong. And 5 + 3 different monitoring and logging tools could be a symptom of chaos in the organization. k8s, and the go runtime and network stack have been heavily optimized by armies of engineers at Google and big tech, so I am very suspicious of these claims without evidence. Show me the resource usage from k8s component overh…

feel the same about helm, it enables versioning and simpler deploy but misses core features

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#209
post #72

Earlier quoted context omitted.

Why would those brick everything? You update node one by one and take it slow, so issues will become apparent after upgrade and you have time to solve those - whole point of having clusters comprised of many redundand nodes.

Not sure if this has changed, but there have been companies admitting to simply nuking Kubernetes clusters if they fail, because it does happens. The argument, which I completely believe, is that it's faster to build a brand new cluster than debugging a failed one.

I had this happen on a small scale and it scared me a lot. It felt like your executable suddenly falling apart and you now need to fix it in assembly. My takeaway was that the k8s abstraction is way leakier than it is made out to be

Re: I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever

#210
post #21

I feel like OP would've been much better off if they just reworked their cluster into something sensible instead of abandoning K8s completely. I've worked on both ECS and K8s, and K8s is much better. All of the problems they listed were poor design decisions, not k8s limitations. - 47 Clusters: This is insane. They ack it in the post, but they could've reworked this. - Multi-cloud: It's now not possible with ECS, but…

How is K8S better for simple workloads? ECS works fine and has way fewer knobs to turn.
Post reply on HN