Posts tagged as cdn

Text

AWS is NOT the prime enabler of scalability

Lately I’ve read a lot of articles proclaiming that scalability is no longer an issue thanks primarily to AWS. As a devops engineer who lives and breathes this stuff, I’d like to point out that there are oodles of other technology advances that are more critical for scalability than simply being able to spin up virtual servers on demand.

The simplest possible example of why more servers != scalability is that of a MySQL query. If you run an unindexed query on a large table, you can add more slaves all day long but you still aren’t going to be able to service requests more quickly. Add an index, and suddenly you can service hundreds or thousands of similar queries with the same amount of resources as it took to run a single unindexed query.

I’d argue that the prime enablers of web scalability are:

  1. Cheap RAM. Storing a dataset in memory improves performance, which means more queries can be served in less time. Servers with 80GB of RAM (or more) are not only possible, but common.
  2. Non-relational databases. Everything gets measured these days, but relational dbs aren’t up to the challenge of storing large amounts of analytics data. Of course there have always been non-relational dbs, but the proliferation of Cassandra, Mongo, and other key/value stores enable us to store massive amounts of data concurrently with single digit millisecond response times.
  3. Content Delivery Networks. Most web requests are for static assets like images, javascript, and CSS. Gone are the dark days of serving these assets using resource intensive processes like Apache. Now our app servers are free to serve exactly that - the application.
  4. Better libraries & documentation. Resources like Cal Henderson’s Building Scalable Web Sites brought modern concepts like memcache and asynchronous queues to the masses. Now documentation is ubiquitous and all web languages offer multiple excellent libraries enabling scalable web application development. 

You might argue that AWS offers many of the services I’ve described above. It’s true. But AWS was not the first to offer them, nor is AWS the only (or even cheapest) option today. 

Text

Five Things To Love (and Hate) About CloudFlare

Update: CloudFlare’s CEO’s response at end of post.

CloudFlare is a service that sits in between your web site and its visitors to make pages load faster and defend against malicious users. The first time I heard about CloudFlare, I was enchanted. At Squidoo, I’ve worked for years to develop a rock solid performance and security infrastructure, and all of a sudden a company comes along that offers many of the same features for only $20/mo.

I’ve been eager for the chance to try CloudFlare, and the newly relaunched CollabFinder was the perfect test. Now that I have some experience with it, here is what I love and hate about Cloudflare:

LOVE

  • Instant performance boost for almost any web site: optimized routing, globally distributed caching of static content (CDN), automatic minification of scripts and CSS.
  • Basic security protection against email harvesters and spam commenting bots, plus a reCaptcha-based challenge page to allow the good guys through.
  • All of the above FOR FREE.
  • 5 minute installation. It couldn’t be easier to get up and running.
  • For $20/mo, advanced security features like XSS and SQL injection protection. 

HATE

  • For a service that’s all about performance, CloudFlare’s control panel feels pretty slow. The page frame loads first, then the main content Ajaxes in a few seconds later. There’s no loading icon, and when the content does appear it’s a little jarring.
  • The Threat Control panel, a radar of suspicious activity identified on your site, is confusing and scary. 



    Everything is red, and it’s not clear what you’re supposed to do or whether you have been harmed. What makes this especially bad is that CloudFlare is geared toward novices who aren’t as knowledgeable as professional web developers.
  • The security features are completely opaque. Options like “Low”, “Medium”, and “High” might be welcoming for newbies, but make it impossible for developers to troubleshoot false positives.
    On CollabFinder, quite a few people had trouble uploading photos because CloudFlare blocked the requests. This happened on some photos, but not others, and we couldn’t find a pattern. Turning the security settings to “essentially off” still didn’t help, and CloudFlare provides essentially no documentation about what types of checks are performed at each security level. We eventually implemented a workaround using cross-domain ajax to bypass CloudFlare’s security feature (yuck).
  • The documentation needs work. First, why is it a wiki? Do you really want your customers editing your support documentation? It might not be such a bad idea, considering how little detail CloudFlare itself provides. Here is the tiny little description of the advanced security features:



  • No 24/7 support options. CloudFlare goes home on the weekends, even though your site does not. Why isn’t there at least an option for premium support?

If I could do it all over…

I’d still pick CloudFlare. For small businesses, side projects, and new ventures, it’s simply the easiest and most effective way to speed up and secure a web site. 

Have you tried it? What do you think?

Update: CloudFlare CEO Matthew Prince confirms via Twitter that CloudFlare is working on the negatives I’ve mentioned and that they do have support staff working 7 days a week. The tweet I referenced above is apparently directed only at hosting partners, not standard customers. Prince touts an average turnaround time of 3 hours on support requests, although there are no guarantees (and I’m waiting on an initial response to a ticket posted 22 hours ago). CloudFlare plans to offer a complete SLA sometime in the future.