> They are instead provided out of the box by K8S, leading to fewer individual components to run, maintain and monitor yourself. You can switch out components at any level, from a single container running your favorite webserver, to a full service mesh, to your own custom controllers.
Fair enough, though I was misled by the word "replaces", which, to my mind, means something different than merely providing out of the box.
> Containers are much smaller than VMs
I don't disput that. I'm also well aware that size matters. However, you initial assertion was that it "removes almost all ops overhead" and that it is "much faster and easier to maintain" (emphasis mine), which merely increasing performance (as performed by computers, not humans), no matter the degree, doesn't do.
I'm still not seeing how the maintenance (done by humans) is any easier (or, for that matter, faster) than with VMs.
> Your comment amounts to a big "what if"
Only on the last sentence asks such a question. The rest of the comment asks different questions, some of which you've addressed above.
> Any competent technical leadership
This is a bit too "true Scotsman" to be useful. The question is what actually happens with actual leadership once a particular tool is in place. Does it encourage (inadvertently or otherwise) long-term dependence on the tool's ecosystem to the exclusion of those bespoke changes, or does it naturally peel away the leaky abstractions once they no longer hold value?
There are lessons to be learned from ORMs. Even early on, there was little (no?) controversy that the best practice would be to start off using them everywhere initially and replace them as needed. I don't believe this practice was followed, despite the pain, at least partially due to the perceptions of ease and consistency in sticking with ORM-everywhere.
> But you definitely don't need to unnecessarily worry about it
You may be conflating premature optimization (a strawman you detail in the next paragraph, which I won't address) and merely considerting the future, the "what if we succeed?" question, which is what I'm advocating.
I say it's quite necessary to at least think about the consequences of a tool choice in the context of eventual success, especially if the initial investment is high, but even if not.
All that said, I hope you've noticed, I'm not actually making any assertions about Kubernetes, just asking questions (and challenging assertions). I tend to take a position of skepticism with anything that seems to gain popularity through network effect, as it becomes extremely difficult to separate facts from hype, even in (especially in?) anecdotes.