I've been playing with a few load-balancing, caching, and high-availability servers to sit in front of my web servers. This is in part to allow me a little flexibility in my configuration, as well as to give me some protection from hackers, and just some experience with some of the myriad options out there.

At the office we're using Varnish in front of our server farms. I also use Squid as a proxy server, and it has capabilities to act as a front-end. Both of these have issues with shared SSL certificates, though, like the one used on this and most of my other sites. I use multi-host certificates becaue of my limited IP address availability (and also for the practice), so having a front-end that can't handle them is an issue.

I've looked at putting another web server with reverse-proxy capabilities in front of my actual web servers; both Apache and Nginx can do this. This seemed less fulfilling, although it would certainly work. While looking at Apache, I noticed they have a project that does this specifically, Apache Traffic Server; this looked promising.

Apache Traffic Server seemed to do what I wanted. It supported all of the SSL trouble-making I wanted, allowed for a bunch of access rules, and there were even packages to install it on my systems. Alas, the packages are all a bit older than the new versions available. Further, I wanted to run this on a zone on my big (RAM and CPU) Solaris system, but their package manager had a very old version available, and the contributed binaries don't have a Solaris 11 version, and the build process is daunting (and I write software for a living), to say the least.

I started also thinking that hand-holding a load-balancing, caching, reverse-proxy system might be a bit more to chew than I really want to attempt. I started looking then for services offered by others. Most of my clients use Akamai for their content delivery; in fact, most of the websites visited (that aren't Google) probably use Akamai for their content delivery. Akamai is a little big for my needs, and doesn't offer a free or very inexpensive level of service. Amazon CloudFront offers a free period, and a seemingly inexpensive offering, but plugging in the numbers from my site statistics led to an estimate of $5000/month for CloudFront; surely something's wrong there as I don't have that many hits or that much traffic.

 What I did find that seems to work is CloudFlare. CloudFlare offers tiered services, including a free service. With their free service, they offer SSL, either passing through to your server or using a free certificate they create. Creating an account is as simple as surrendering an e-mail address.

Adding CloudFlare caching services to a domain requires surrendering DNS to them. In a lot of cases, that was no big deal as DNS is often handled by the registrar and contains a couple A (name to IP) or CNAME (aliases to other A) or MX (mail server) records. These seldom change and are pretty safe to put anywhere. A nice thing about letting your registrar or other service handle the DNS is that, well, you don't have to. A change to the normal DNS handling is the ability to toggle whether a record goes through the CloudFlare cache or not, but otherwise I found the DNS configurations to be just about as complete (for my DNS needs) as my registrars. This is also their way of validating that you're the domain owner or administrator; can't change the name servers in your domain if you aren't.

Once the CloudFlare set up is complete, and DNS propagates a little, they'll start fronting your site. By default, they cache images, JavaScript, and CSS. There are some hoops to jump through to have HTML pages also cached. They do that all by extension, so if there's clever URL magic in your site that doesn't use a typical extension, they won't recognize it.

Once configured, a little tweaking might need to be done to get SSL certificates where they didn't exist before, but it's choosing the right drop-down value and waiting. Then, poof, valid, browser-trusted SSL certs, for free. In front of your cache server, for free.

The possible negative impacts of using the CDN are really limited to the source of the traffic, and the rate of traffic. The source of the traffic will all have a raw IP of the CloudFlare servers (clients connect to them, and they to your server). There is an additional header that passes along the original IP, so it can be captured and logged as necessary. The rate of traffic also changes. Since images and other files are cached, there's a lot fewer of them requested; this is part of the desired service, but it can cause an odd looking skew in traffic reports.

Also, depending on how your site operates, there can be changes required to data passed to a web page as JavaScript, such as cross-site JSONP. The JSONP will be seen as JavaScript and get cached by the CDN. The default is to cache for four hours, so if that JSONP is dynamic but not in a way determined by the path or query string, the results might be undesired.

To mitigate this, CloudFlare does offer an ability to add rules to URLs (and patterns of URLs) to reduce or even eliminate the caching. This can also be useed to add caching for HTML pages. Normally, pages ending in HTML extensions, or pages without extensions, aren't cached. Rules can be added to encourage caching of those pages, too.

The tiers allow larger traffic and better analytics, as well as a little more fine-grained control over some of the things like the caching rules. Depending on your sites' traffic, though, the free might be enough.

Oh, and especially if you're just looking for SSL certs, make a CloudFlare, configure it with their SSL, and then don't cache anything. Free. Or at least until you need additional rules or more bandwidth.