A couple of weeks ago it occurred to me, after not posting any blog entries for some years, that using Google’s Blogger platform to serve my content has become tired and antequated. I’ve also held concerns about how invested I am in the Google ecosystem for the past year or so, and how much of a product of their’s I have become. So I decided to spend a day reviewing my blog options.
There are quite a number of options available for the modern day blogger. Here are a few that I looked into:
- Hosted virtual private server, install blog software of your choice, offered through many hosting providers
- Choose the blog software, and find a shared hosting provider
- Use a text editor and write all HTML from scratch myself (hey, I was a web developer once), host on a static hosting service
- Use a NodeJS blog scaffolding tool, host on a static hosting service
I came up with a few requirements to help assess each option, here they are:
- Cost: ongoing costs must be affordable for an individual - anything more than $10 per month seems a bit excessive
- Custom host name: I like to have my name in the URL, and recently purchased a few names to do just that
- SSL enabled: Google Chrome, today’s most popular browser, has started to mark non-SSL sites as “not secure” in the address bar, and while some would argue this is a vanity component, for someone who works in the industry, an SSL certificate makes everything look that little bit more professional
- Easily customised blog template, preferably without having to brush off my PHP skills and learn a whole new ecosystem of plugins
- Simplified blog posting procedure: I really don’t want to go through hoops to post a blog - the process has to be quick so I can pump something out and move on to the next task
- Redundancy: I’m not too concerned if the site goes offline for a couple of hours for whatever reason, but I want to recover easily if the host goes down or data is lost
Hosted options considered:
- WordPress Virtial Private Server (VPS) hosted on Azure
- WordPress site hosted on a shared service like BlueHost or DreamHost
- Drupal hosted on either a VPS or shared service
Having been in the web industry for some time, I often find myself inextricably sticking with the status quo. Hosted blog sites are the status quo, and for someone who works in the cloud every day, hosted sites like blogger, and the many number of WordPress hosts out there, just seem too outdated. They’re also expensive.
I’m recommending cloud based solutions every day for my customers. The pricing of these solutions are often measured in “per-gigabyte-data-transfer”, not “per-month” so why not apply this thinking to a blog solution? This becomes even more attractive when the “per-gigabyte” cost is often in the fraction-of-a-dollar price point, and blog sites should be lightweight in size.
The price of WordPress shared hosting varies a great deal. Some US-based providers offer WordPress sites for as little as USD$2.95 per month, while some Australian based hosts seem to offer similar products for as much as AUD$20 per month. That price variation seems just a little bit weird. Considering my desired audience will likely be world-wide, hosting the site in Australia could add latency to requests that reduce the perception of a professional site.
While considering the hosted options, I thought about the size of the provider, to take into account their scale and whether that might increase the performance and resiliency of the site. I’m not interested in some tiny company with a server room in woop woop.
Hosting a blog in a cloud-centric world - breaking it down to first principles
When you think about what a blog is, it can be broken down into the following parts:
- a hosting platform for reasonably static content
- a management tool to assist in writing content
- (possibly) a commenting system to enable feedback - although, this is debatable; I’d prefer to receive feedback through more established social media e.g. Twitter and LinkedIn
Having worked in designing Azure and Microsoft 365 solutions, the mark of a cloud based solution is how well it shifts as much of the workload away from the server, over to the client. When it comes to a blog site, the workload that must remain active on the server-sdie is is the serving of content. The overall workload of creating content is a relatively small in comparison. Why dedicate, and pay for, a hosting platform that’s priced to be there for you 24/7 to do a task that you might do for an hour once or twice a week?
Enter: Hexo - the NodeJS based scaffolding tool
Over the past number of years, working on modern SharePoint solutions, including SPFx, I’ve found myself to be very familiar with NodeJS, and git. I also find myself writing a lot of documentation in Markdown format. It was a bit of a hallelujah moment when I came to find a bunch of NPM packages that let you create static content from a templating engine, and these templating engines often start with Markdown as a source format.
There is beauty to this approach. When I want to write a blog, I’m always in front of a full fledged PC or Mac, with the NodeJS development platform already installed.
So I settled on the templating engine Hexo, and I’m now writing my posts (including this one) as Markdown in Hexo’s source format.
I might digress slightly here to note Microsoft’s recent change in approach to documentation writing, shifting away from the internally hosted / secured TechNet / MSDN platform, to a new platform that has the following characteristics:
- source controlled in git (actually in all products I’ve seen, the source repo is public, via github)
- content source written in Markdown format
- (presumably) statically hosted for publishing via the docs.microsoft.com domain
Though the scale is hugely diffrent, the approach I’m taking to this blog site, has some parallels with the the architectural design of docs.microsoft.com, in terms of end-to-end content creation and delivery.
All that said, I’d acknowledge that anyone not already familiar with git, and NodeJS, may find this element of my blog publishing architecture a little hard to use.
Hosting the content in Azure - Static sites with Storage Account
There is also beauty in the way the approach of generating static content opens up a large number of low-cost hosting options. Not least of which: Azure.
I like the idea of keeping my service providers consolidated, not least because its a nightmare to reemember which site I need to log in to in order to update a service. I use Azure on a daily basis, so I’ve chosen to host as much of my personal online capabilities there as possible.
I recently saw, in my social feeds, a feature I hadn’t considered before - Static sites with Storage Account has made it to General Availability status in Azure. It’s almost as if fate brought me to this position. The feature set is exactly what I’m looking for:
- lightweight and cost effective (by my estimates $0.11 per gigabyte, I’m unlikely to hit even a gigabyte)
- redundant
- tools that integrate in to my desired development environment
- offers custom domains through a simple CNAME implemented in DNS
One feature I was looking for is missing in Storage Account static sites - SSL. The solution to SSL? Create an Azure based CDN endpoint with custom domain, and enable SSL there.
SSL is super quick to configure on an Azure CDN; with the right DNS configuration, the process of generating a cert is automated, and free.
Quick, easy, and cheap
I used the following articles to set everything up:
- Static website hosting in Azure Storage
- Use Azure CDN to access blobs with custom domains over HTTPS
All-in-all, I spent more time investigating my options than I did setting this up. I may be exagerating a little, but I think I could count, on my fingers and toes, the number of clicks required in the Azure portal to have a production-ready, redundant, super-fast, secure blog site hosted in Azure.