3 ms·
It 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 sh
by ndriscoll 2y ago
It 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.