I spent quite a bit of effort trying to get this blog from idea to running. For a long time (around twelve months), I’ve had ideas about how I wanted to store, version, and deploy my blog. Thist post will take you through what I finally settled on.

What Was I Trying to Do?

From the onset, I had two primary technology objectives:

  1. Host on Azure
  2. Build using Markdown, and a static site generator

The Azure part wasn’t very hard. Microsoft has updated their Blob storage service, enabling users to host static sites from storage blobs. I did have to do some work to figure out how to get a custom domain name with HTTPS support enabled, which I was able to work out using the Azure CDN documentation. I also needed to get an SSL certificate, but it turns out that Azure CDN has certificate management features as well. I just had to go in and turn on HTTPS. As I followed the directions in the documentation, the Azure infrastructure went and found the owner information for my domain, performed all the necessary validation, created, and distributed the SSL certificates.

I had a few reasons for wanting to create a static site for my blog. The first and most obvious is that static sites generally cost less money to host. The second is that I really don’t want to perform dynamic rendering of the content, because I know it will change infrequently, and the nature of the changes will generally be the addition of new content. Adding a new post usually means updating the root file /index.html, and the addition of new content under /posts/.

One of the nice-to-haves that I had on my list was having a CSS pre-processor (aka SASS and LESS). There were two projects I was aware of that fit the bill:

I also evaluated (and built a site with) the StackOverflow-powered MarkdownSharp project (more info). The big problem that I had with this was that I was re-writing stuff that was already built in to other projects, using C#. While I love writing code (I’ve toyed with writing my own Markdown parser+emitter, similar to the Roslyn project), I didn’t want to embark on a potentially several-year long project just to start bloggging. I’m also not terribly experienced in this space, and if I wanted to do somethin with my idea, felt that contributing to an existing project was probably best. I also recognized that I wasn’t prepared to make such a time commitment.

In the end, I picked Jekyll. For my needs, I had two primary use-cases:

  1. I needed the ability to host my blog locally for development
  2. I needed a static generator that I could run before publishing

Dynamic generation is fine when I’m trying to preview stuff, but as I mentioned, static hosting is cheaper. I can provide filtering, for instance, on the client (in the browser) - and plan to in the future - but I have absolutely no interest in paying for content generation on someone else’s servers (at least, not more than once, when the build definition runs).

When I was getting started, I looked at Harp quite a bit. It was appealing: everything was available via the NPM toolchain. I’m a Windows user, and NPM is available everywhere. I used Harp for some documentation and note-taking sites, and it was wonderful. But I for some reason wanted something different.

Then I started using Jekyll. I’d known about it for some time - Joe Duffy runs his blog on Jekyll+Github - but I never quite jumped on board. Part of it was because of the Ruby dependency: I didn’t want to have to learn another language, runtime, and toolchain. But then Microsoft announced the Windows Subsystem for Linux (WSL), and I realized that I could use Ruby and Jekyll fairly easily, without having to change my entire machine. If I have an issue with WSL, I can just nuke the whole image, re-install Linux (if I want to), and move on with my life. With system installs, that’s not exactly the case, because you end up with things like package caches on your system, which chew up space. I have absolutely zero interest in trying to clear out package caches as part of a system cleanup. I recognize that some of this is solved very easily using either Docker, or by just re-building your machine, but I didn’t find either of those options to be particularly accessible or appealing.

As I’ve gone down the path of building a site using Jekyll, I’ve come to love it. It’s a very powerful engine. Additionally, the open-ness of Azure Pipelines makes building and publishing “on the server” very seamless for me. Git might be the best distributed file system on the planet (for plain text), and I’m storing everything about my blog in Git. Azure Pipelines pick up all the changes that I push, build them, create a Release, and then execute the release to get my blog into Azure. It’s all very seamless. At some point, I’m going to look into building and publishing the whole thing using Pulumi, as I feel that would create a lot of value for me, and for others.

Wrapping Up

In a nutshell, this post was about the architecture of my blog. I’ve more or less described everything about the architecture. There’s more to come in the future: I still don’t have a search feature, and it still looks a little bland to me, but I’m happy with where it’s at, and where I plan for it to go.

Thanks for reading!

- Brian