3 ms·
L4 vs L7 load balancing and the ability to send clients to specific addresses seem like major differences to me? I'm not seeing how subdomains are "archaic". It
by ndriscoll 2y ago
L4 vs L7 load balancing and the ability to send clients to specific addresses seem like major differences to me? I'm not seeing how subdomains are "archaic". It's also obviously desirable on the user side in a world of everything using TLS to allow better network management (e.g. blocking some services like youtube and ads on a child's device while allowing e.g. maps. Or if reddit used subdomains, you could allow e.g. minecraft.reddit.com without allowing everything else) without needing to install CAs on every device to MITM everything.
- noinsight 2y ago> allow better network management Yeah, this would definitely block that. DNS-based (hostname) allowlisting is just starting to hit the market (see: Microsoft's "Zero Trust DNS" [1]) and this would kill that. Even traditional proxy-based access control is neutered by this and the nice thing about that is that it can be done without TLS interception. If you're left with only path-based rules you're back to TLS interception if you want to control network access. [1] https://techcommunity.microsoft.com/blog/networkingblog/announcing-zero-trust-dns-private-preview/4110366 https://techcommunity.microsoft.com/blog/networkingblog/anno...
- abxyz 2y agoSubdomains are archaic in the context of high availability. 15 years ago, it was impractical to expect a single system (google.com) to reliably handle hundreds of millions of requests per second and so distributing services across subdomains was important because it distributed the traffic. Today, hundreds of millions of requests per second can be handled by L4 systems like Google Cloud and Cloudflare. Today traffic to a subdomain is almost certainly being routed through the same infrastructure anyway so there is no benefit to using a subdomain. That's why I describe subdomains as archaic in the context of building a highly available system like Google's. If you're Google in 2010, maps.google.com is a necessity. If you're Google in 2025, maps.google.com is a choice. Subdomains are great for many reasons but are no longer a necessity for high availability.
- ndriscoll 2y agoIt has nothing to do with high availability. It's useful to separate out different traffic patterns. e.g. if you're serving gazillions of small requests over short lived connections, you want a hardware accelerated device for TLS termination. You'd be wasting that device to also use it for something like video (large data transfers on a long-lived connection). An L7 loadbalancer (i.e. one that's looking at paths) needs to terminate TLS to make its decision.
- abxyz 2y agoYou're making a different point. Of course, there are use cases for subdomains, I'm talking specifically about the transition of maps.google.com to google.com/maps. google.com/maps always made sense but wasn't technically viable when Google Maps launched and that's why they've transitioned to it now. I'm arguing that Google Maps being on a subdomain was an infrastructure choice, not a product choice.
- msm_ 2y agoI'm not trying to be argumentative, but by saying: >Subdomains are archaic You presented a bit different argument. Also I disagree - maps.google.com is a fundamentally different service, so why should it share a domain with google.com? The only reason it's not googlemaps.com is because being a subdomain of google.com implies trust. But I guess it's pretty subjective. Personally I always try to separate services by domain, because it makes sense to me, but maybe had the internet went a different path I would swear path routing makes sense.