-
Notifications
You must be signed in to change notification settings - Fork 376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use a custom domain for CDNs #8602
Comments
@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? |
It's an anti-pattern. This is the pattern that we're currently mitigating with azuredge.net.
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. |
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. |
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. |
Yeah, we're focusing on different problems. For me, the important lesson for this repo specifically is to ensure we have aka.ms links so that if we have to change in the future, we can update those without needing to redeploy or merge anything. That's the state we're in hence why we can add the custom domain later as a hygiene option but there is no rush to do so as there's no pressing need. You've been driving the all-up effort where there are critical situations where customers have copied off the links we, ourselves are using. In those situations, it's not ideal to use a direct CDN link as any customer who copied it off would be broken which results in a lot of need for additional communication and care when changing that. As I've covered elsewhere, that is not the situation for the templating repo. Hence why I'm saying the risk here is low and there's no rush. As you've pointed out, that nuance is not really great to need when messaging with folks less familiar with the situation. |
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.
The text was updated successfully, but these errors were encountered: