Building Your Own CDN for Fun and Profit • Hacker News Board

Re: Building Your Own CDN for Fun and Profit

#61

Post by askbjoernhansen » Thu, Feb 15, 2018, 6:41 AM UTC

rsync wrote: post #49

I have always thought it would be a fun and inspiring project to deploy a global CDN ... my career and my lifelong hobby have both been "UNIX sysadmin" and I love running networks ... However, I spoke about this to some ISP/NANOG folks that I trust and they said that running a real CDN is a nightmare because all of your links (providers) hate you ... you're producing the exact opposite of the traffic that they want a…

Not at all accurate, assuming the "real CDN" is well run.

Re: Building Your Own CDN for Fun and Profit

#62

Post by boundlessdreamz » Thu, Feb 15, 2018, 7:12 AM UTC

ksec wrote: post #44

kirankn wrote: post #2

We currently use KeyCDN which works out well, both performance & money wise. You may want to try it out.

Why KeyCDN ? Why not MaxCDN or Fastly etc?

MaxCDN performance is not great. Fastly charges for requests in addition to bandwidth.

Re: Building Your Own CDN for Fun and Profit

#63

Post by gunzel » Thu, Feb 15, 2018, 10:43 AM UTC

janoszen wrote: post #56

sciurus wrote: post #55

Earlier quoted context omitted.

> But CloudFront charges $600 per month for custom SSL certificates This is misleading. Cloudfront doesn't charge anything for putting your domains on an SSL cert that uses SNI. They only change you if you need a cert without SNI, which requires them to allocate a dedicated IP address to you. I'm hosting my personal blog on S3 and cloudfront, with SSL, for less than a dollar a month. Performance and capabilities are…

If you are fine with having slashes at the end of your URLs and you do not want to do anything too complicated like content negotiation for image types, S3 and CloudFront is fine. The moment you turn on Lambda@Edge, to do the magic, things get slow after a period of no traffic. I plan on expanding on the featureset, so no S3 for me. :)

Did you consider using periodic calls to keep the Lambda@Edge functions "warm"? I've been playing with Zappa (https://www.zappa.io) for standard Lambda and it sets this up by default.

Re: Building Your Own CDN for Fun and Profit

#64

Post by janoszen » Thu, Feb 15, 2018, 1:13 PM UTC

gunzel wrote: post #63

janoszen wrote: post #56

Earlier quoted context omitted.

If you are fine with having slashes at the end of your URLs and you do not want to do anything too complicated like content negotiation for image types, S3 and CloudFront is fine. The moment you turn on Lambda@Edge, to do the magic, things get slow after a period of no traffic. I plan on expanding on the featureset, so no S3 for me. :)

Did you consider using periodic calls to keep the Lambda@Edge functions "warm"? I've been playing with Zappa ( https://www.zappa.io ) for standard Lambda and it sets this up by default.

Yes, but it's kind of a whack-a-mole since their reuse times are not public AFAIK, so it would constantly need tuning as they develop the service.

Re: Building Your Own CDN for Fun and Profit

#65

Post by chousuke » Fri, Feb 16, 2018, 11:09 PM UTC

tpetry wrote: post #21

chousuke wrote: post #12

Earlier quoted context omitted.

I think it should be clarified that "destination" refers to an IP address, not an individual host. My understanding is that anycasting means a single address corresponds to multiple hosts achieved by simply advertising it from several sources with BGP, and you will often still have multiple redundant routes to any of the individual hosts behind the anycast IP because most locations will have redundant internet links.…

Google Cloud Global Loadbalancer seems to do this fancy session mirroring because you only have one IP for the http load balancing. I am very often impressed by the GCP products.

There are other techniques that Google's routers will most likely use to load-balance traffic transparently to multiple hosts. A relatively simple way is to hash the (source, destination) address pair of the IP packet to determine which host to forward the packet to, so it doesn't necessarily require mirroring or any state. Only seamless failover when the host fails requires the fancy tricks.