Use a custom domain for CDNs

[richlander]

We have a new rule on the team ... only use cloud resources via custom domain and don't use aka.ms links as a wrapper/abstraction.

https://github.com/dotnet/templating/pull/8595/files

We can work with you to create a new domain.

[marcpopMSFT]

@richlander what's the drawback of using aka.ms and what's the push to move to custom domains? This is a low-volume non-critical use case and we don't expect customers to ever use the cache links directly. Switching to domains sounds like requiring a lot more networking domain knowledge and potential for longer-term maintenance costs. Is the goal to avoid aka.ms in order to avoid impact from outages in the redirection service?

[richlander]

It's an anti-pattern. This is the pattern that we're currently mitigating with azuredge.net.

Is the goal to avoid aka.ms in order to avoid impact from outages in the redirection service?

Not really. We should follow the same patterns for all of our CDN usage. It's simpler in aggregate when everything is done the same way w/no exceptions.

[marcpopMSFT]

The original problem was hardcoded links to the prior CDN. Using a custom domain is one solution. Using aka.ms links is an alternative.

There are tradeoffs to each. Using the custom domain allows devops to fix it centrally but they won't have any knowledge of the scenario impacted. The benefit of the aka.ms links is that my team can handle the transition and testing at the same time without having to coordinate with devops. So in my mind, it's a tradeoff decision rather than a string anti-pattern as that's a strong statement then I think is warrented.

IE the search cache could stay on aka.ms links forever and it'd probably be fine.

[richlander]

Using the aka.ms link and the custom domain are logically separate.

Using a CDN-specific link in any way is an anti-pattern. This is a clear learning from the last few weeks. Hiding it behind an aka.ms link is just messy.