[the_af]

Isn't the article's vision of things like Kubernetes (and similar) a bit too idyllic?

I've heard talks by experienced K8s adopters (I want to say "Kubernetes failure stories", but googling comes up with similar hits but not the specific talk I was thinking of) where they mention that when K8s goes bad, it has all the negatives or knowing the "traditional" tech stack plus all the failure modes of K8s itself. They argue that it's more stuff you have to know about, not less; and when trouble hits, it can get very complicated to understand why.

(Not picking specifically on K8s; this applies to similar orchestrators/container tech).

[herio]

I agree.

Ultimately I think it's just another leaky abstraction like so many other things we do. Wonderful when it works as intended and less so when it goes wrong.

I also think that the more layers of software and management you add in makes it more complicated to troubleshoot, you simply get a lot more to learn in order to understand things.

One of my life philosophies is "It's always more complicated", meaning when you think you understand something you've barely just started scratching the surface of the complexity of it.

I can understand the pull of the container and lambda style workflows, you gain feature velocity which is ultimately what gains you the business. On the flip side, I also suspect that it builds technical debt faster.

[jeffbee]

Some of these stories (I just Googled for "kubernetes failure stories") have little to do with K8s. This one[1] is just whining that his app is slow when it runs out of CPU. That's more of a "I don't know what I'm doing" story, isn't it? Lifting the CPU rate limits in a container is not exactly a cost-free magic wand.

1: https://medium.com/omio-engineering/cpu-limits-and-aggressiv...

[yjftsjthsd-h]

> That's more of a "I don't know what I'm doing" story, isn't it?

Sure, but k8s is big enough that "very few people know what they're doing" is a valid argument. It's loosely like saying that git sucks because the technology is solid but it's extremely complex and hard to get a grasp on.

[jeffbee]

I don't think the ergonomics of k8s are anywhere near as bad as those of git. I think the perception of k8s as complex and confusing is promulgated by people who already don't understand how their process starts and runs on any given Linux box without container orchestration. Naturally these people are overwhelmed by adding k8s on top.

The article to which I linked describes itself as "a wild ride of discovery" but all that has been discovered is basic aspects of the Linux process scheduler. The author could have skipped the wild ride if they had understood Linux first.

[p_l]

Add to this conspicuous lack of good bottom-up description of how things mesh together, and suddenly instead of having complex system built out of simple parts people face complex system built of magic. It's a credit to k8s that you can trudge forward in the second case, but I'm too divorced from "k8s newbie" to reliably check what's the current "newbie introduction" :/

[the_af]

I cannot speak for the article you linked to, but the Zalando guys (from the "failure stories" talk) seem pretty experienced and do seem to know what they are speaking about...

[the_af]

This is closer to what I meant: https://www.youtube.com/watch?v=6sDTB4eV4F8

Still not the exact talk, but I think it's from the same guys. I remember they explained how with K8s, the "surface area" of problems grows almost uncontrollably. You have all the problems of doing things manually (or at least, when things go wrong you must have a very good grasp of them), plus all the problems of K8s.

(Do note they are not arguing against K8s, just pointing out its multiple pitfalls)