3 ms·

> eg if you want DDoS protection, or geolocated content delivery end points, or the ability to scale traffic cost effectively should your content go viral None

by deno 9y ago

> eg if you want DDoS protection, or geolocated content delivery end points, or the ability to scale traffic cost effectively should your content go viral None of those things require CDN. Doing your own SSL termination is not hard. And HTTP 2.0 almost let’s you get away without it.

laumars 9y ago
> None of those things require CDN. I wasn't implying you required a CDN to address those points. The issue the GP raised was about "a single company proxying a significant amount of internet's traffic" which is a much larger topic than with regards to CDN alone. However to address your point specifically, many of the larger players in the CDN market do tout the features I discussed as a key reason to use their infrastructure. Which makes a lot of sense because if you are going use a proxying CDN like Akamai, CloudFlare or CloudFront then you would expect some level of DDoS mitigation, geolocated nodes, and, most importantly, offloading. > Doing your own SSL termination is not hard. And HTTP 2.0 almost let’s you get away without it. SSL termination is completely irrelevant to the points myself and the GP raised. While some low traffic blog sites might use (for example) CloudFlare for their free SSL termination (less of an issue these days with the likes of LetsEncrypt) it's fair to say that the vast majority of CDN-proxied traffic is behind a CDN for reasons other than obtaining a free SSL certificate - reasons such as those I described above. Source: my experience delivering a multitude of high profile, high traffic sites (eg 100,000+ concurrent users) for a variety of different clients.
- deno 9y ago
  SSL termination is the most latency sensitive thing in the stack, I wasn’t talking about provisioning. With HTTP 2.0 you get to reuse the connection, so it’s not as critical. Anyway my point was you can get all those features without involving heavy L7 multitenant MITMaaS. I stand by it. > Which makes a lot of sense because if you are going use a proxying CDN Yes, but is proxying CDN the most optimal solution if you need those features. Isn’t that the relevant question.
  - laumars 9y ago
    > SSL termination is the most latency sensitive thing in the stack That really depends on your infrastructure and how it copes with load. Latency can be introduced in so many different areas. While some parts of the stack might operate at a much lower latency, they can quickly cause far more significant bottlenecks once throughput is increased - even just marginally. This is why load testing is so important - it's easy to make generalised statements but it's even easier to overlook something or poorly tune one of the numerous ratios one defines in a typical complex stack. > Anyway my point was you can get all those features without involving heavy L7 multitenant MITMaaS. I stand by it. It's an irrelevant point because the discussion was never about whether it was possible or not to do the above. > Yes, but is proxying CDN the most optimal solution if you need those features. Isn’t that the relevant question. * It's cheaper than rolling your own solution, * It's quicker than rolling your own solution, * And it's easier to maintain than rolling your own solution. Plus, frankly, most companies don't have the infrastructure talent to build solutions that could compete with the uptimes, throughput and latency that they would get from Akamai, Cloudflare or AWS. So basically "yes"; in a great many cases a proxying CDN is the most optimal solution for the same reasons why writing backend web code in higher level languages is optimal than writing them in C or assembly.

by deno 9y ago

laumars 9y ago

> None of those things require CDN. I wasn't implying you required a CDN to address those points. The issue the GP raised was about "a single company proxying a significant amount of internet's traffic" which is a much larger topic than with regards to CDN alone. However to address your point specifically, many of the larger players in the CDN market do tout the features I discussed as a key reason to use their infrastructure. Which makes a lot of sense because if you are going use a proxying CDN like Akamai, CloudFlare or CloudFront then you would expect some level of DDoS mitigation, geolocated nodes, and, most importantly, offloading. > Doing your own SSL termination is not hard. And HTTP 2.0 almost let’s you get away without it. SSL termination is completely irrelevant to the points myself and the GP raised. While some low traffic blog sites might use (for example) CloudFlare for their free SSL termination (less of an issue these days with the likes of LetsEncrypt) it's fair to say that the vast majority of CDN-proxied traffic is behind a CDN for reasons other than obtaining a free SSL certificate - reasons such as those I described above. Source: my experience delivering a multitude of high profile, high traffic sites (eg 100,000+ concurrent users) for a variety of different clients.

deno 9y ago
SSL termination is the most latency sensitive thing in the stack, I wasn’t talking about provisioning. With HTTP 2.0 you get to reuse the connection, so it’s not as critical. Anyway my point was you can get all those features without involving heavy L7 multitenant MITMaaS. I stand by it. > Which makes a lot of sense because if you are going use a proxying CDN Yes, but is proxying CDN the most optimal solution if you need those features. Isn’t that the relevant question.
- laumars 9y ago
  > SSL termination is the most latency sensitive thing in the stack That really depends on your infrastructure and how it copes with load. Latency can be introduced in so many different areas. While some parts of the stack might operate at a much lower latency, they can quickly cause far more significant bottlenecks once throughput is increased - even just marginally. This is why load testing is so important - it's easy to make generalised statements but it's even easier to overlook something or poorly tune one of the numerous ratios one defines in a typical complex stack. > Anyway my point was you can get all those features without involving heavy L7 multitenant MITMaaS. I stand by it. It's an irrelevant point because the discussion was never about whether it was possible or not to do the above. > Yes, but is proxying CDN the most optimal solution if you need those features. Isn’t that the relevant question. * It's cheaper than rolling your own solution, * It's quicker than rolling your own solution, * And it's easier to maintain than rolling your own solution. Plus, frankly, most companies don't have the infrastructure talent to build solutions that could compete with the uptimes, throughput and latency that they would get from Akamai, Cloudflare or AWS. So basically "yes"; in a great many cases a proxying CDN is the most optimal solution for the same reasons why writing backend web code in higher level languages is optimal than writing them in C or assembly.