Serving Static Sites

I admit I had an ulterior motive for my static sites post: I’m heading towards a longer discussion of non-static, stateful sites. How we architect for statefulness has massive implications for the kinds of monolithic services we see on the web today (think Facebook) and the kinds of privacy-eroding policies most of these services employ to reach profitability.

Before I get there, a few of you asked how I generate and serve my own blog. So this post is a (very) quick side-bar on the topic.

My blog is generated by Jekyll. While there are countless static site generators out there, Jekyll feels like it has rightly earned its crown as the default choice for static site generation when your project has no specialized needs. Jekyll’s documentation is straightforward and complete and, with few exceptions, I’ve rarely had to do back flips to build the kind of sites I envision with the tools Jekyll hands me.

My blog is served using Amazon S3 and CloudFront¹. I use an elegant gem called s3_website to get the job done; it does exactly what it says on the tin, reliably, and mercifully in accordance with its documentation. To use s3_website, create a simple YAML configuration that specifies your S3 bucket, AWS credentials, and (optionally) CloudFront endpoint. Invoke s3_website apply to turn your YAML configuration into AWS reality. After this, your site is ready to serve content. Simply run jekyll build to generate your static content and s3_website push to deploy it. The s3_website gem is quite smart; it will do nice things like selectively invalidating CloudFront content if necessary.

It took me about ten minutes to get going with s3_website; I highly recommend it. The folks at MadeByMedia posted a number of other handy Jekyll + s3_website tips that are worth looking at, too.

[1] CDN nerds will point out that CloudFront’s latency — especially on little trafficked sites like mine — can be quite variable, that cache invalidation is expensive and sometimes slow, and that S3’s consistency model² is not always desirable for website content. To this I say that the perfect is the enemy of the good enough.

[2] I’ve always wanted to do a footnote within a footnote! S3’s consistency model is read-after-write for new objects, and eventual for all other actions… unless you’re in the us-east-1 region, in which case it’s simply eventual for all actions. Pretty strange, that.