| ▲ | vaylian an hour ago | ||||||||||||||||
Naive question: How important is it to use a CDN in the first place? Why can't you just serve the content yourself? | |||||||||||||||||
| ▲ | viraptor an hour ago | parent | next [-] | ||||||||||||||||
It depends on what you're trying to serve, but it's used to either save you money or as an insurance (or both). You don't need a CDN overall. But if you grow large enough, at some point you'll run into one of these three situations: - Your public traffic costs you so much to repeatedly process that it's cheaper to let some service cache the common responses instead. (Where the cache size is larger than anything you'd want to support yourself. For example, if it's <1G and survives your service restarts, you may want to do it yourself) - Your customers on the other side of the world start complaining that the resources take ages to load. - Someone floods you with enough traffic that you can't respond to real customers traffic anymore. You get a ransom email to pay them to stop. But there are enough groups doing that that paying is useless because someone else will try again in a few days. If you're providing a service where people pay you to use the website, you're losing money until you solve this problem. | |||||||||||||||||
| ▲ | _joel an hour ago | parent | prev | next [-] | ||||||||||||||||
Reduces latency when the cached content is served from a local cdn pop, allows you to absorb some level of DDoS, can absorb traffic spikes more easily so infra can be more static, reduces load on server if assets are dynamically generated on the backend but can are cacheable, some senses can lead to simpler deployment as you serve assets from an object bucket, so no need to deal with keeping that data in your cluster, but that's minor. There are downsides too, cost, over caching, privacy/security perhaps too. | |||||||||||||||||
| ▲ | unglaublich an hour ago | parent | prev | next [-] | ||||||||||||||||
Because an average request would have to travel half the globe, so setting up a simple HTTPS connection would already take a second. That's completely unacceptable for static content. Not only would transfer be slow, they would also be much more pressing on the network as the request would occupy huge stretches and many interconnects and switches. Furthermore, it hardens the website against DDoS and adds robustness for regional failures. | |||||||||||||||||
| |||||||||||||||||
| ▲ | pluc an hour ago | parent | prev | next [-] | ||||||||||||||||
This article being down/slow is a great response. | |||||||||||||||||
| |||||||||||||||||
| ▲ | esseph an hour ago | parent | prev | next [-] | ||||||||||||||||
The site this is about is current down due to HN traffic. Lol | |||||||||||||||||
| ▲ | embedding-shape an hour ago | parent | prev [-] | ||||||||||||||||
Depends on your use case. If you have a very inefficient backend (maybe legacy project?), you have massive amount of traffic (say 100K req/s or above) or you really must have sub-500ms latency absolutely everywhere in the world, then it might make sense to slap a CDN (or similar) on top of that. In pretty much any case outside of that, it makes no sense to waste the time, money or effort on CDNs. But, all the CDN companies seemingly have convinced half the internet that you absolutely must use a CDN, otherwise you'll get hacked/broke/killed/sent to the moon, and they've been successful with this campaign too seemingly. | |||||||||||||||||
| |||||||||||||||||