[antonvs]

Kubernetes can be a godsend at larger orgs.

We have six dev teams and are just about done with migrating to k8s. It's an immense improvement over what we had before.

It's a version of Greenspun's tenth rule: "Any sufficiently complicated distributed system contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Kubernetes."

[eep_social]

I think six dev teams is small in terms of kube. I wouldn’t be surprised if that’s close to the perfect size to move onto kube and create and adopt a standard set of platform idioms.

at orgs significantly larger than that, the kube team has to aggressively spin out platform functions that enable further layering or risk getting overwhelmed trying to support and configure kube features to cover diverse team needs (that is, storage software doesn’t have the same needs or concerns as middleware or the frontend). this incubator model isn’t easy in practice. trying to adopt kube at this scale is very challenging because it requires the kube team to spin up and out sub-teams at a very high rate or risk slowing the migration down to a crawl or outright failure and purchasing e.g. off the shelf AWS because teams need to offboard their previous platform.

[antonvs]

> I think six dev teams is small in terms of kube.

I don't doubt it. By "larger" I just meant larger than something like "running my servers on FreeBSD/OpenBSD and jails or VMM respectively" above, which sounds like a one-person operation.

> I wouldn’t be surprised if that’s close to the perfect size to move onto kube and create and adopt a standard set of platform idioms.

My previous position was at a company about 5x the size, with many loosely related enterprise and government products that they sold into markets in at least 20 countries. They also used k8s quite effectively.

But, I think the key is that you mentioned "the kube team". Having a single team responsible for everything k8s-related at a large org is likely to make it difficult to be effective.

For supporting individual dev teams I think you need people on those teams who have at least some of the necessary knowledge, so they're not entirely dependent on a central team. Even a watered-down version of what devops was supposed to be about is better than nothing.

[throwaway838112]

No, most large orgs do not need it.

[antonvs]

Completely unsupported assertions are the least interesting kinds of comment anyone can post.

Besides, this particular comment would need to explain why it’s likely that its unsupported opinion is correct, rather than all the counterexamples that exist in the actual highly competitive industry that’s heavily using this system.

There’s a fundamental conflict there that doesn’t work in favor of your inchoate opinion. The most likely conclusion is that there are factors at work here that you don’t understand.