Hacker News new | ask | show | jobs
by k3n 4915 days ago
I think the idea is that hosts like Google (and ostensibly, Mircosoft) are going to have availability that far exceeds your run-of-the-mill website. Those big hosts generally are going to provide five 9's (or more) availability, whereas %your_random_site% is probably going to be on the order of three to four 9's, at best. So more often than not, the point of failure is going to be your website...not the CDN.

If you have the infrastructure ($$$) to support your own web services on the order of 99.999%+, then by all means host it yourself, otherwise you're most likely never going to have a problem with it (especially if you include a fallback method).

4 comments

I'm not sure I follow. Obviously if my host goes down my entire site will go down - this is not the point. The point is that when my host is up, what % of the time will my site still be down? Well if you use a CDN that % is greater than zero. If you use two CDN's the percentage is compounded.
And that's why you have a fallback, to fully mitigate any CDN downtime (how little that it may be). It's like a spare tire in your trunk.
If your webserver is down what does it matter that the CDN that hosts your library scripts is up?
It doesn't, but that was never the point of the CDN.....
I don't understand this logic entirely. If your site is unavailable due to normal, unavoidable probabilities in reasonable uptime, why does it matter if the CDN is hosting your scripts or not? Your site isn't going to be around to access them.
It doesn't matter in those cases; it DOES matter for the 99%+ of the time that both the CDN and your site are working optimally. In theory, the CDN should provide the best all-around experience for users (caching, lower latency, parallel loading, etc.). THIS is why you have the CDN -- not as some fail-safe for when your site goes down.
I agree completely that your average website will have less uptime than the CDN. The problem isn't that the CDNs are less reliable, it's that it's VERY unlikely that your site will experience downtime at the same time as the CDN. This means your site reliability is the combination of the downtime of the CDN as well as your own.
Yeah, but if you gracefully handle those failures with local fallbacks, then the CDN's downtime is a moot point.
See the rest of the comments in this thread about why the fallback can be painfully slow if the CDN is down. I saw your previous comment about making an ajax request with an adjusted timeout, but this is not ideal for making cross domain script requests for a number of reasons. For one, CORS needs to be enabled. Another is that you now have to create a script tag and take the responseText and jam it in there. This is going to be slower than just creating a script tag and setting the src attr.

If you are going to have a fallback, and that fallback may take seconds to activate if the CDN is down, why not just make the fallback your primary?

You can easily specify how much time a CDN will have to respond as you can see in my example in another comment: http://news.ycombinator.com/item?id=5003129