IT Should Just Work - 2021 Site Refresh

This site, I.T. Should Just Work, has had a makeover - both cosmetically and also under the hood. This post will take you through the new design, migration process, and reasoning behind this refresh.

A little bit of history

This site, in one form or another, has been around since 2008. It came from humble beginnings on a blogger.com site but has spent most of it’s life sitting on a self-hosted WordPress instance. The WordPress platform was serving me well- and I would still recommend anyone wanting to start out making their own blog goes and spins up a free, hosted instance to get the ball rolling - but I was finding performance would often suffer and because I was self-hosting I was spending too long fiddling with patches to keep up-to-date and secure.

:right
Performance can be fixed with more expensive hosting, but I’d started hearing about this static site generator called Hugo which could take my posts and wrap all the nice pages, categories, indicies around them. This appealed both to my wallet, static HTML hosting at this scale is cheap and/or free, and to my technical inquisitiveness. I sat down, did my research, and set out building a new site and migrating my old content across.

The new design

This is the end result. I have a private github repository which holds all my posts (as individual markdown pages) and images. Github Actions run when there’s a commit to this repo and pushes the content out to an Azure Static Web App. So to write or edit posts I open up Visual Studio code on my laptop, modify or create files as needed, then just click on commit and sync the changes with Github. Git means I have a local copy of the site on my laptop I can work on offline, and test before committing. There’s a very straightforward tutorial on setting that all up here: docs.microsoft.com

Web access to the site is handled through Cloudflare who were already handling DNS and SSL certificates for the old site. Rather than being backed by my hosting provider, this now points at the Static Web App in Azure.

Infrastructure Design and Workflows

Hugo offers a wide choice in themes, and I went for the VMware Clarity-based offering. It’s nice and clean and doesn’t complicate my message with design.

Benefits over WordPress

  • Cost- The largest benefit here is financial. All of the components above are currently free of charge. I pay the regular annual fee to register the domain name, but all the Cloudflare, GitHub, Hugo, and Azure components are (currently) free to use. Whilst WordPress was free to use, my hosting was not.
  • Performance- Because the host is now just delivering HTML (and pictures) there’s no compute bottleneck for the PHP to run. I’ve also lost the need for the MySQL database which sat behind WordPress.
  • Better drafting/ staging capabilities- Whilst WordPress allowed me to have draft or private posts that only I can see, this configuration enables me to change the entire site at will. I can do this locally running Hugo on my laptop, or by publishing to git branches- these appear as seperate website slots in the Static Web App.
  • Future portability- having moved from WordPress I have a clear understanding of how fiddly that can be. Whilst export tools exist, there are so many customisations that can happen to a WordPress site over the years getting one to work smoothly can be awkward. With this new setup I can quickly and easily move the content to another Hugo deployment elsewhere, or use a different pipeline, or take the raw content files and import/transform them into something else entirely. I’ve also got the option of just keeping the HTML output hosted for the community to continue using when I give up tech and decide to take up professional bungee jumping.

Migration

The trickiest and longest bit of this process was the migration of the content. Setting up the new site was straightforward, quick, and painless, but I ended up manually copying, pasting, and reformatting page by page from the old site to the new over a couple of months.

Yes, there are more automated tools and methods out there but I took this as a good opportunity to fix broken images, review tagging, and correct some internal references. It was also rewarding to be able to look back on over a decade’s worth of writing and bring back the memories of meetups at VMworld, useful snippets of code I wrote, or that time someone spilled strawberry sauce on their phone. If you’re planning on doing something similar with your own site I’d recommend considering the tools available for you, and working out if you want that trip down memory lane.

Before

After

Conclusion

To finish up, I’m glad I made this move. The site now feels quicker and (I think) looks a bit smarter. If you’re starting out blogging yourself I’d suggest you have a look at this sort of coniguration, but don’t write off the possibility of starting out with a blogger or wordpress.com site- remember it’s the content that really counts here.