CloudFront vs CloudFlare: We have a winner

DZone 's Guide to

CloudFront vs CloudFlare: We have a winner

· Cloud Zone ·
Free Resource

This a follow-up to my first post on CloudFlare. This will make more sense if you read that one first.

John from CloudFlare was kind enough to invite me (well, technically I kind of invited myself) down to the CloudFlare offices. Conveniently located just a few blocks from where I'm working! Gotta love San Francisco's SOMA district. We talked about my earlier post.

I gotta say, everything from configuring CloudFlare on my system, to writing up the first article, to visiting their office has been incredibly fun. I've really enjoyed it.

On the snake oil

As you remember from my first post, I had a big issue with CloudFlare. I couldn't quite put my finger on it, but it sort of just felt like marketing spam. I'm also not the only one. The odd thing was, I couldn't find anything they were actually doing wrong. Now, I think I've decided what my problem was:

They're just too damn cheap.

I worked with a client once that was paying thousands/month on their CDN through EdgeCast. I found it incredibly hard to believe that CloudFlare would be willing to provide a similar service for absolutely nothing. Yet, there they are.

Most of my conversation was trying to find some loophole where you would have to start paying more if you were really hammering their system. John mentioned they have several high profile sites (such as 4chan, youm7, the 6th largest site in Egypt, nerdlist, and laughingsquid) that are on their system. They have >100,000 sites, which makes them much bigger than I imagined. He said that some of the high-end clients to pay a bit more, but that's for an SLA, not bandwidth.

He said a few times the pro package was working well for them. Even at 20 bucks/month. No matter how big you are.

I had some concerns that CloudFlare might increase it's rate and remove it's free plans. John assured me they will be adding more pricing tiers, but they will not be removing, or taking away functionality from the free plan. Still though, even if they did dramatically increase their rates, there is no vendor lock-in. It would be trivial to switch over to another CDN.

I still don't understand how a company could have a 2k/month EdgeCast bill, and CloudFlare would be willing to let them on for free with the basic features. If this is working for them, either the other CDNs are totally overcharging, or CloudFlare is just running so efficiently internally that it's not necessary to charge more than they are.

On stability

Now, Andrew Lippert has a great comment on the original post. John mentioned that he knew Andrew quite well, and that Andrew has been very active in the community for CloudFlare. John replied to Andrew directly on the same post.

I won't reiterate what they said on there. I also cannot comment on the stability of CloudFlare as I have not had any downtime myself. Their site did have a lot of slow responses and timeouts while I was using yesterday, but mine has been fine. It's only been 24 hours though, so who knows. John did mention that they're working hard to make sure the platform is incredibly stable.

On the security

One of the interesting problems CloudFlare has is they can't quite find their core value. Are they a CDN? Are they a security company? Something else? It's hard to tell, they do all these things.

I didn't mention the security much in my last article. This is really only because on my blog I don't really care.

What I do find odd though, is that according to them 21% of the traffic to my site is 'threats by attackers'. From reading my logs... I find this hard to believe. I'm wondering how much of that is false positives.

One neat feature he mentioned is it actually is looking at sql injection and xss attacks that might be coming across. As you'll see in my security article, I'm a big fan of another layer of prevention for this.

Now the big comparison: CloudFront vs CloudFlare

It's hard to not choose CloudFlare here. Here's what CloudFlare has:

  • Much better interface
  • Much easier to setup
  • Can optimize many things not related to just static assets
  • Security preventions (CloudFront, being solely a CDN has none of this)
  • Analytics to measure how well the CDN is helping your server
  • It's freaking free

What about CloudFront? I can't think of much, I would appreciate thoughts in the comments.

The only thing I can think of is that CloudFront has much more control. If you need to invalidate cache on an individual asset, for example, CloudFlare can't do this (but John specifically mentioned this is coming). I imagine there might be similar issues such as this, but I can't think of any else to be honest.

There is a Client API for CloudFlare I did not know about in the previous article: http://www.cloudflare.com/wiki/Client_Interface_API I wouldn't call it extensive, but it's nice they've got something to potentially build out. There is some neat things in there though, like querying for search terms hitting the site.

The lack of control is intentional on CloudFlare's side though, they don't want you to have to think about things like that.

In summary

John asked me if there would be any reason I wouldn't go with their system in the future. To be honest, I couldn't think of one. CloudFlare is providing an excellent service for nothing (or next to nothing). It's also packed with a million times more features than any other CDN.

Bye CloudFront, I'm going the free route. Here's the proof.

Bonus: S3 and CloudFlare how-to

I hate to turn this into a how-to, but I did get my question on how to get S3 working with CloudFlare working. It's so easy it doesn't warrant it's own how-to:

Just make your s3 bucket the full host you want. For example, for me it was 'content.jeffdickey.info'. Then set your DNS CNAME in CloudFlare to 'content.jeffdickey.info.s3.amazonaws.com' (obviously replacing my bucket name with yours). Then you'll be good to go.


Source: http://jeffdickey.info/cloudfront-vs-cloudflare

cloud ,cloudflare ,infrastructure

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}