If someone wants to take you down they'll just bombard you with traffic, and this won't help you there. Having been the victim of several DDoS attacks over the years, almost all of them haven't been on the application layer.
This blog post is a good starting point for the kinds of strategies you need to fill that gap in protection.
GA would cost you more than 50ms too. More so than a CDN controlled analytics. But obviously that cost with CDN is an upfront latency rather than the more hidden cost with background loading of GA. So arguably GA's cost is less "bad" than the CDN's cost.
Personally speaking, I prefer the CDN approach as it produces web pages with a lower browser footprint which I think does improve the user experience (though I'm not implying that GA give a bad user experience!).
GA does give a greater breadth of information than CDN analytics though. Often that's the real deal breaker since analytics is usually driven by project managers / clients rather than by the developers.
> Charts that show how much static traffic you saved are nice, but with bandwidth close to free, it's not a big deal.
Oh it's definitely a big deal if you serve high traffic websites ;) I've spent hours working against those kind of reports on projects that were seeing 100k concurrent users. I will say that these graphs aren't so much about judging what bandwidth can be saved but more about judging what requests can be offloaded. The idea being the fewer calls to your origin servers you need to make, the more resources you have available in your farm for generating the dynamic content (dynamic content you cannot cache!). This also has the potential to save you money in server costs (depending on how they're licenced) as well as improving site performance at peak times.
> CDN analytics need to be better than GA at which point I will not only trade off latency but convert to premium all the way.
Indeed. GA will likely always be better from an account management perspective. But as a devops engineer, CDN analytics fulfils my needs. The great thing is that we have a multitude of options we have available :)
In all seriousness though, it might help to look beyond the very specific set up of your present company when asking about why other people opt for other CDN services. But for what it's worth, I've not experiences the same degree of latency issues with either Cloudflare nor Akamai that you've described. And I have done extensive load tests.
I remember listening to your talk at dotGo 2014 :-)
I tried CloudFlare in November 2012 (3 years ago, and not 1 year ago as I wrote in my previous comment). At that time, the origin server was hosted by Typhon in France. I remember that after having enabled CloudFlare, the latency was significantly increased. I haven't kept the specific timings, but to give you an idea, the response time was like 100 ms without CloudFlare and 500 ms through CloudFlare.
That said, it was a long time ago and I can guess things have changed a lot since. So I did a new test today. The origin server is hosted by DigitalOcean in Amsterdam. The median response time from my machine is around 100 ms. After enabling CloudFlare, I cannot see a significant difference in response time. The median response time, and the distribution of response time, looks very similar.
I guess that during the last few years you have expanded your network and your connections with the major hosting providers (Amazon, Google Cloud, DigitalOcean, Linode, etc.). Maybe it explains the difference between today's test and 3 years ago?
In general, is it useful and/or recommended to use CloudFlare in front a fully dynamic service, for example a HTTP-JSON API, with no static content (no images, no stylesheets, no scripts), and thus no need for the CDN feature?
In general, is it useful and/or recommended to use CloudFlare in front a fully dynamic service, for example a HTTP-JSON API, with no static content (no images, no stylesheets, no scripts), and thus no need for the CDN feature?
We do have lots of customers who do that. Two reasons: Railgun and Security. Railgun gives speedups for the JSON because of the ability to diff the boilerplate JSON. Security for APIs is of course important and clearly attackers like to go after APIs.
About security, what are the specific security features you're thinking of?
Just hoping you can give a concrete example, as I'm not super familiar with this stuff.