Because no engineer building application software wants to specify their infra down to the component level. Infra is awesome when it is Somebody Else's Problem. Docker compose was popular, Heroku was popular, Vercel is popular. Infra is good whenever there are reasonable defaults, good ergonomics, and requires no maintenance. Kubernetes is a DIY cloud solution. It's great if you are trying to build AWS/GCP/Azure, not so great if you want to deploy your app for the cheapest cost possible while not being constrained by the limitations of Vercel/Heroku.
The worst is clouds like fly.io that believe their value prop comes from stuff like "edge computing" while their main offering is half baked, under documented, and unreliable. People want better, cheaper managed infrastructure. Good managed infra should be small overhead on top of the raw compute cost. Nobody complains about LAMP PHP deployments because it was good value and offered what people wanted.
I'd love to connect with you and talk more about this! I'm working for a company building something that addresses the problems you describe [1], ditto for pricing model.
It’s often an overkill solution. Most often you only need a VM and a few scripts to help with backup and deployments. Which can be done really cheap. But you bring in k8s, which is a nice abstraction, but often more complex than the services it hosts.
Kubernetes provides good abstractions for managing deployments, but Kubernetes also comes with massive overheads. The overheads come in terms of the many yaml files needed to define services, and in terms of complexity of the underlying infrastructure for hosting the cluster itself.
If you were in a bigcorp in charge of orchestrating 1000s of services, that overhead could be worth it.
However, if you were a solo dev trying to deploy one service, that overhead is really bad.
What you'd normally think of as Wireguard allows routes at connection time sure, however OP wants a VPN which allows peer B ("server") to define a route and advertise that route to peer A ("client"). So one day the client would route 10.1.0.0/24 down the wireguard tunnel, but not 10.2.0.0/24, the next day however from changing peer B, the config on peer A would change.
Obviously there are many things you could do to allow this (run a routing protocol, build a custom client which gets route information, etc), but the "out of the box" wireguard is a kernel interface, a wg command, and a utility script (wg-quick). I think there are some gui based clients for non-linux based OSes, but it's the same principle.
DNS is nothing to do with the wireguard kernel or userspace, it's configured in the "wg-quick script" (there's a bash function called set_dns), but you can do that however you want.
Wireguard alone isn't what an enterprise would consider to be a "VPN solution", it doesn't push configs from a central location, it's very much a peer-to-peer tool. You can build "enterprise" features like centrally defined routes or DNS on top of that, or not, it's not opinionated.
Well, speaking for myself, I was against them from the start. Maybe the rejection of distributed objects (when it came) was a hot trend also but it didn't make it wrong.
Some productivity guru would say you have the correct mind set.
Chasing the perfect productive setup is a big sophisticated procrastination trap.
But tmux does bring in value. The fact it makes it possible to keep a remote session running even when you lose connectivity is worth learning at least 5% of that tool.
I have always thought it was super sexy to have all these panes available with an editor, logs, debugger opened at the same time ; but the reality is that I cannot work with 20 characters columns.
I use a 4k display set to HiDPI (1080 lines) and simply switch between my full-screen panes.
Sometimes I will split my tmux window vertically because I can deal with fewer lines but I never split horizontally.
What's wrong with developing software knowing it will be hosted on a k8s cluster?
You can install a local k8s cluster will plenty of tools helping you with secrets management, observability, ingress, scaling, storage.
Why the hate?