Blog anatomy

Introduction

Surprisingly, to-date, I wrote little about the technologies behind this blog or about the tech journey it went on. Recently, I decided to improve the process behind it and update the tech stack as it aged. As I was already in that mental context, I wanted to share it and document some findings that may be useful to you.

Knowing it is a static site, you might be wondering what is the big deal? After all, it's just a bunch of html, css and js files, right?

Well... the creative, publicly visible layer is mostly in the static files, but the blog is more than just that. There are plenty of complexities, some are even similar to the ones encountered when working with traditional servers.

The static site was originally generated using Jekyll but a few years ago I've ported it to Hugo.

Visually it may seem familiar to you as I’m using a popular theme Hugo Clarity with very little extra styling. I have, however, tweaked the backend of that template quite a bit over time to suit my needs.

There's some integrations with third party services, namely Cookie Script for consent management, Google Analytics for web analytics, pagefind for statically generated site search feature and PayPal for donations.

The blog is served from AWS. The main cloud services I use are S3, CloudFront, Route53, CertificateManager and CloudFormation. There are a few others, but are either less important or too obvious to mention.

The provisioning process is mostly coded (more about that later on in this series). I invoke a shell script and that sets some context, delegates to a few tools, and creates the cloud resources. If I’m done with it (let's say short lived test environment) I trigger another script and, within minutes, the resources are gone (that reduces cost and so does to the maintenance, operational overhead, drift, and attack surface).

Initially, I used Terraform for provisioning as I felt comfortable with the tool, it is (still) very popular and well-supported, and it did everything I needed it to do. Then in 2021 I needed a Terraform project that I could translate into AWS's CDK so that I can evaluate what CDK was about, in comparison to Terraform.

All the provisioning, diagnostic, and authoring tooling I use is containerized, and I use docker to build, run, and manage containers locally.