I think it gets used as part of 'best practices' a lot where it was not actually helpful. But it hasn't been my experience that knowing it is a meme or even it being a bad thing. It just gets a little silly when you see stuff like a service managed by k8s that probably made more sense as a library
Personally I could never get into k8s. For most of my use-cases, simply getting a VPS, or having a Dockerfile is enough.
Most apps can run fine for millions or hundreds of thousands of user sessions on a $5-$50 VPS. People prematurely optimize for scale, adding a lot of complexity that only makes development slower, and by having more moving parts, there are more things that can break. Start simple. Scaling is mostly a solved problem nowadays, if you quickly need to scale, there are always solutions to do so. In the worst case, you have to scale horizontally, and if you reach the limit of horizontal scaling, other your app is inefficient, or your business is already successful, so you are no longer in the "start" phase.
Yep, strong agree here, and indeed the modern hardware can achieve mind-blowing stuff. I have used a $250 laptop (i5 CPU that's now 8-9 years old, 16GB RAM, SATA SSD) to stress test some of my Rust apps and I could achieve ~250K requests per second.
Sure that doesn't apply to all tech (f.ex. my favorite Elixir is much slower than this) but for most intents and purposes a plain old VPS with good backups is quite enough and always will be. Or if you are particularly paranoid like myself: have a load balancer and have 2-3 copies of your app servers, 1 DB server, and overzealous backup scripts.
I usually want to load-balance between different hosting providers (so if AWS goes down, I still have DO running). From what I've seen, most of them only provide load-balancing within their local networks.
One solution I was thinking of, is to load balance using DNS, or at least to have failure recovery using DNS (one server goes down, update the DNS to point to the other server). I am fine with a small downtime.