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.
We tried it, setup was easy, but our response time for dynamic content increased by 150 millis so it didn't work for us. It's worth noting that their model is different from CDN - they proxy all of your traffic through their own servers.
That's not atypical for a CDS these days; fastly and cloudfront can work the same way, e.g. https://aws.amazon.com/cloudfront/dynamic-content/. How else do you expect them to cache and serve your dynamic content?
Some organisation do just that. But having your entire site behind CDN does have additional benefits besides mitigating DDoS attacks. Such as allowing you to handle other kinds of service outages more effectively (eg busy pages). They can offer you analytics, allow you to separate different traffic under the same domain name (sometimes handy for SEO), etc. Some CDN providers also do some cool stuff like enable IPv6 on your site even if your origin servers are only running IPv4 - but that's more a niche time saving feature than some "must have" deal breaker.
I like analytics if the price is less than 50ms per request. We use GA and statcounter for analytics anyways. Charts that show how much static traffic you saved are nice, but with bandwidth close to free, it's not a big deal. 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.
I'm really interested in knowing if other HN members have similar data points on this topic. I tried Cloudflare one year ago and had the same issue (response time increased a lot).
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?
Yes. A lot has changed since then. Including a whole lot of stability and expansion. I think you'd have a different experience today.
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.
AWS said at re:Invent 2015 that about 15% of DDoS attacks on AWS were application layer [1]. Some were state exhaustion at 20% (SYN floods, etc.) but the vast majority (65%) were "volumetric" attacks, meaning layer three like DNS reflection and SSDP reflection.
This blog post is a good starting point for the kinds of strategies you need to fill that gap in protection.