Kubernetes is for orchestrating a distributed system. What I was suggesting is to (1) make a monolith and (2) make it fast, light and high-throughput. The goal of your service is to reliably serve users at scale; this is just another way of doing it, just much more esoteric.

A "C++ monolith" allows me to potentially bypass a lot of this deployment stuff because it could serve lots (millions) of users from a single box.

In a world where your architecture is that simple I don't think kubernetes would be the choice for long.

I think for the average application there's still something to be said for manual cross-layer optimization between infrastructure, application, and how both are deployed.

What I mean is we can't yet draw too clear a line between the application and how it's deployed because there are real tradeoffs between keeping future options open and getting the product out the door. A strength of kubernetes is that if you get good at it it works for a variety of projects, but a lot of effort is needed to get to that point and that effort could have gone into something else.