Hardly blogspam, the source you cited is listed clearly as a source at the bottom of the article. It even gives credit to the referrer.
"John said Sally got a noew job, how do you feel about that Debrah?", "That's great." said Debrah. "I can't wait to tell Frank!" "Frank, John just told me that Sally got a new job!"
It also contains 200 words of original commentary as a lead-in, and the report is less 300 words in total.
We tried to use Cloudflare when they teamed with Dreamhost a few months ago. We had more downtime than uptime....
Though this is super-relevant because during the struggle with Cloudflare, we released an article about LOIC and how easy it is to reveal the locations and identities of individuals involved in a DDoS attack using LOIC.
Sorry for the trouble you had. Did you submit a support ticket to CloudFlare? Sounds like something was blocking requests from our network.
LOIC and a number of the more public DDoS tools make the attackers' identities relatively easy to track. The big attack we saw last Saturday is much more difficult to trace both because it is originated with a UDP request (the headers of which can be forged) and because it is reflected off open resolvers (essentially laundering the identity of the attack's source).
Honestly we were confused by the whole partnership. We kept submitting tickets to Dreamhost which they did a poor job of fulfilling. We liked the idea of Cloudflare and we were mostly willing to stick it out. Not only that, but we had several great ideas about how we might leverage your offering against some other things that we wanted to accomplish.
The real reason that we stopped using Cloudflare is that when you were unable to serve the cached page, it throws up a Cloudflare branded page. We thought that those sorts of error pages would diminish our image as an open source publication because it seems to suggest that we can't rely on our own tools and abilities.
If we were able to display a "Powerbase" branded 404 type page, we would have been more satisfied.
If you're a paying customer, you can fully customize the error pages. Probably easiest if you just sign up directly through us if you want to do something like that. We can get you setup:
I also had problems when I tried CloudFlare. Different problems, but it cost me a few days contacting users and apologising before I U-turned and switched the nameservers back.
I unfortunately use PayPal and their Instant Notification thing, basically a callback to a web page with a POST about the transaction that just happened. Upon receiving the POST I can then do things like notify the customer, dispatch goods, award virtual goods, etc.
The problem I had was that after putting my website (in the London Linode datacenter) behind CloudFlare, PayPal started randomly failing to reach the callback page.
PayPal, being PayPal, failed silently for a few days before finally sending an email to say that they couldn't notify me of transactions. I figured it out just before that though, because users were getting the CloudFlare "site offline" message.
The pages on my site are 100% dynamic, so nothing was cached by the feature that keeps a site online.
My biggest problem with CloudFlare was visibility for debugging: I had no visibility.
If it wasn't for my users letting me know and PayPal emailing me confirming what I thought... I wouldn't have known. Even then it took too long to find out, over a week from when it started to fail silently.
According to Linode there was no downtime in that period, and according to my server logs load was never above average and there was no reason it should've been unable to be reached.
Did I submit a ticket? I submitted some questions beforehand and got back answers that were very friendly but not technically detailed. That's also how I found the interface, I couldn't debug using CloudFlare, no way to answer the questions "What is happening? Why is it happening?". So no, when I figured it out I wasn't going to stay with CloudFlare as even if it was resolved I would still lack visibility for future problem-solving.
In the end it was costing me goodwill with my users.
I wanted things you didn't provide:
How often did CloudFlare fail to contact my network?
Can I see a chart of such failures over time?
What were the failure error codes and times so that I can cross-reference them to my logs?
Basically: I wanted transparency so I could have confidence in the service, and detail so that I can debug failures when they occur.
And I was going to email this as it's really a "just to let you know". But you have no email in your HN profile, and looking through the support emails I had I see tenderapp.com and can't make a guess what your email address may be, and I pinged you on Twitter but no response and it's very late here... so posting it so you can see.
If you add ways for developers to debug issues when using CloudFlare then I may well be tempted back in the future. The fundamental premise is a good one and I really wanted it to work (paid for the Enterprise level, had every intention of using it). But when failing silently costs real money and customer goodwill, I don't feel I had a choice but to U-turn very rapidly.
As soon as I was off CloudFlare, PayPal Instant Payment Notification worked again and there hasn't been a single failure since.
I had similar experiences with CloudFlare. Wanted to use them, but they could give me absolutely 0 visibility into why they thought my site was down. I could load it in another tab using the raw address while CloudFlare kept serving the couldn't contact page.
Support was fairly unhelpful, basically just saying "sometimes this happens, and it usually clears up".
For this to work you can use the direct.[domain].[tld] (or any record you create with the grey indicator) record which does not get served by CloudFlare. When you use CloudFlare with the orange indicator, your traffic will be proxied through their network... this can mean when calls look similar, they will be cached. you either have to tweak the settings, or as aforementioned, avoid CloudFlare when dealing with callbacks.
Ah, but then PayPal IPN callbacks would get through, but the users would still get broken pages.
Or are you suggesting bypassing CloudFlare for all dynamic content? In which case, why use them?
I actually did use them just for a CDN for a few more days. I use a second domain (sslcache.se) to proxy inline images in user generated content that doesn't originate from an SSL site but the user is viewing my site over SSL. Similar to this https://github.com/atmos/camo , except mine isn't written in node.js
Even then, users complained of broken images when they were logged in (on SSL).
The very basic thing: CloudFlare fails silently, sometimes. Well, that still happened with very basic content. From CloudFlares perspective the sslcache.se service was a site of static files, as I prime the content (download in the background) when a user submits the content. By the time the request for an item goes to CloudFlare the image is already being served from a local file system.
CDN only, it still errored enough that the end user noticed. And still without any information for me to resolve it.
I do use CloudFlare for a large amount of websites (dynamic content) and have not had a similar experience.
If CDN is your only purpose? this mostly only useful for static files like JS, CSS and HTML. Somehow your answer is not clear what you try to accomplish. Too little information to go by. If you experience issues with their service, bother them more to get it resolved. Any gain you have improves the service for others.
In the worst case you can always look at other services. I am not sure but I believe Amazon CloudFront provides a similar solution.
I wholeheartedly agree. The lack of transparency is CloudFlare's single largest problem from my perspective. I really wish the analytics package offered more than just a few pretty aggregate charts. Insight into failed requests to my backend servers would be a major help in troubleshooting, and with integration into their API, could serve as great early warning for when things are going wrong at the CDN level.
I'd also love to see the option of periodic uploads of raw traffic logs to an S3 bucket or similar. Something akin to how AWS CloudFront handles raw logs. I believe raw logs are currently available on their enterprise packages, but this seems like basic functionality (that would provide much of the needed transparency) and should be included in all of the paid plans.
