Earlier quoted context omitted.
If all you're ever doing is hosting a static blog, then yeah, you don't need something like Kubernetes; however, if you want to host other services (e.g., database, authentication, comments, etc) then it quickly behooves you to build on some higher-level platform or else you'll end up building your own (poorly) and missing out on all of the experience, documentation, and tooling that are publicly available for Kubern…
Sorry, but we did all of that 20 years ago, and those approaches remain a lot simpler for basic use cases. You know, like serving 100k dynamic pages/hour database backed site. (That's what I was doing 20 years ago, how about you?) See https://pythonspeed.com/articles/dont-need-kubernetes/ for some of the reasons NOT to use Kubernetes for this. With, of course, a giant exception for two cases. The first is, as with th…
Yeah, we did, and they were complicated then and they're complicated now. The difference is some of us have decades of experience which make them feel simpler.
> And if you think that Kubernetes is always the right approach, then you clearly are NOT aware of the tradeoffs.
I was very explicit that Kubernetes isn't always the right approach. Allow me to quote myself: "If all you're ever doing is hosting a static blog, then yeah, you don't need something like Kubernetes". My point is that things like Kubernetes and Docker Compose are increasingly viable defaults for nontrivial cases. In other words, if you know you're going to have a bunch of services to manage, it's a lot easier for most people (i.e., those lacking decades of experience) to manage them with the aforementioned tools rather than trying to build an equivalent "platform" from scratch.