I think I could have worded that better. By "in the WireGuard setting" I mean "doing the job most startups will use WireGuard to do", which is, manage remote access to internal resources in the cloud.
I don't think overlay networks are pointless; I am enthusiastic about them. But for the remote access problem, what I want and what I'm writing about is streamlined VPN software, not a new overlay.
Fair enough, although… you know more about this use case than me, but wouldn’t you generally have a large number of servers in the cloud you want to provide remote access to? So if you’re using WireGuard, either you have to configure each client to talk to each server it needs access to – which could be good for security, but sounds like a pain to set up – or you have a central server that serves as a hub for all the VPN traffic. In your blog post you said you just had to “point the client at the server”, so I’m guessing you’re envisioning the latter. But then wouldn’t an overlay network work better in many cases? For example, if you have cloud servers in different geographical locations, and as the developer you’re near one of those locations but far from the VPN server, you’d have lower latency connecting directly…
I'm imagining simply replacing OpenVPN servers with WireGuard servers, retaining the VPN gateway model; one WireGuard instance acts as a routing gateway for any number of servers.
I don't think overlay networks are pointless; I am enthusiastic about them. But for the remote access problem, what I want and what I'm writing about is streamlined VPN software, not a new overlay.