[nwmcsween]

The problem is you eventually need the things k8s offers and you end up implementing part of k8s, badly. I've seen bigish places that state "we aren't Google" as an argument to not use k8s, containers, etc but don't consider that their tech stacks are a Hodge Podge of bespoke glue, a mass of technical debt and a bus factor of generally 1 or 2.

[majormajor]

The question they should be asking isn't "is this tech stack perfect or a mess" it's "is this actively preventing, or about to prevent, us from meeting our uptime and cost and development goals"?

The idea that a shop that built a messy system will suddenly build a non-messy system just if they pick up a new set of tools - that they don't have practice with anyway! - is exactly the silver-bullet fallacy. The system turned out messy because it's complicated, switching to a very complicated tool doesn't take away the complexity, it just changes the way you manage it.

The last couple Kubernetes shops I worked at were that exact sort of hodge podge of custom glue with high tech debt and low bus factor. Just even doing something "simple" like "ssh into the box and poke around" when the two wizards are out suddenly has a huge learning curve. ;) So then you get into discussions of "oh you should've been using managed kube" or "oh, don't use TF -> helm -> kube, use [other way] of managing it" or blah blah.

After you fuck it up a few time you might have enough useful experience so that you can build it well next time... just pray that by then we're still using the same tools. :D

[nwmcsween]

There is a huge learning curve with k8s and there really needs to be a "k8s the good parts" for tooling to use. The problem with k8s vs $custom_system is k8s is somewhat well thought out and $custom_system is generally not.

[sirwhinesalot]

As someone who works on a hodge podge of bespoke glue, a mass of technical debt, a bus factor of 1, and a docker swarm setup, I don't really see how k8s would help ;)