Hosting this Blog

It’s been a busy year, I really haven’t had a chance to work on any personal projects. However, now that the holidays are here and COVID is still active I’ve found a bit more time than usual to work on a few things.

Initially when I created this domain and started hosting websites it was really intended to support my learnings but quickly became something I leveraged for customer demonstrations. As such, this site changes a lot, traditionally, not visually but the technologies under-pinning the site certainly have changed. Coming into 2022, this will be no different!

That being said, I often have a few objectives when it comes to hosting these sites:

1. These Sites are hosted against my personal credit cards, I have no interest in spending more than $100-$200/yr of my own money to support this initiative.
2. My clients and customers expect their sites to withstand DDoS, Zero-Days, SQL Injections and other Layer 7 attacks; this is a site hosted by a tech person. I expect my favourite trolls and script kiddies to be active and busy. (This isn’t an invite, I perfer to use vulnerability scanners but I know I don’t control you and wouldn’t try!)
3. In order for me to leverage the site for demos, Infrastructure as Code and Automated deployments need to be a thing so tucked in behind all of this is usually some automation.
4. Yes, this site may be a bit of a lab but I expect it to perform just as well as any other site!

So for 2022, I wanted to try and build the leanest serverless website I could stripping out a lot of the frameworks and keeping the site as lean as possible. However, a website without content is boring so I wanted to make sure updating content was easy. For the last year most of notes have been taking in Markdown and that’s worked really well for me. Since this is a project site I thought it would be great if I could continue using Markdown since I have tools I’m already comfortable with and adding my notes would be far more simple rather than having to re-type it all.

Okay, so we know we wanted to use Markdown for content, now the question became how are we going to serve this content and how are we going to publish new conent. There are a fair number of tools out there that can convert Markdown to static sites, for this blog I took a look at Hugo and MkDocs. Transparently, I have very little experience with either of these tools today but tried to make a decision on which way I wanted to go. For me, I didn’t have very complex requirements and both of these worked. That being said I chose Hugo because I found it far simplier to put together and orchestrate. (This blog was built in 6 hours) - I am aware of Jekyll and other options out there for static site generators but honestly, Hugo was one I read through and it just clicked for me. You should choose your own Static Site Generator based on your requirements. You may need more extensibility than I do or want to hand your content differently. Honestly, there are so many options out there you may also just have to pick a starting point. For as much as I’m using Hugo here, I will admit the themes are not the most straightforward to wrap your head around, I think that’s where I spent the largest amount of time.

In order to make this all work well for me, I wanted to author from my laptop and save drafts to the cloud. This is where I deviated, maybe not the most ideal but I’m leveraging a Git compatible cloud repo and as I save content files commits and uploads to the cloud repo. I have 2 branches, a dev branch and a master. The master branch I use to push things into the blog and the dev branch is mostly for content being developed with deployment capabilites to a dev site. Once code is checked in there is a pipeline that collects the new Markdown files and puts them into Hugo which then generates the static sites content and pushes it into dev/production sites respectively.