If you saw my previous article, why I chose Hexo for my Technical Blog you may be wondering, why the move to Hugo now?

I’m not going to spend a ton of time recapping all of the various options as I already did that in the previous article. Hugo was the close second last time around, I even mentioned it could be a coin flip!

I spent a bit of time kicking the tires on Hugo for some test projects and really liked how the templating worked. I was also a fan of the various themes that were out there and available and decided to go with Mainroad which I’ve modified a bit to suit my needs.

I also wanted to check out a few other things - which finally caused me to make the switch!

• Azure Static Web Apps - This was launched a while back, and I’ve been following it since. I was previously using Static website hosting in Azure Storage. It has some nice integration I wanted to try which brings me to…
• GitHub Actions - I’ve not had the opportunity to use it yet, and since it has direct integration with Static WebApps - it was an opportunity kick the tires.

So switching to Hugo has given me the chance to check out three new pieces of tech! Hard to argue with that!

I’ll go a bit into detail on the process and steps I took to make it happen.

It has been just about a month and a half since my first day at Microsoft! I’ll soon be in the field helping customers on their journey to the cloud. As part of my training I’ve been able to obtain three Azure certifications I’ve been looking to obtain for some time!

Originally when I setup my blog on Static website hosting in Azure Storage I went with Azure CDN because I wanted to have an SSL endpoint. As of right now, you cannot do custom SSL with static website hosting unless you use Azure CDN.

But then I hit another snag, you cannot redirect the root domain and redirects in general were a bit too complex for a simple project like this one. There is a user voice suggestion for this feature but it remains under review. This started to bother me because I wanted to do redirects with SSL but couldn’t because the I could not install the certificate generated by Azure CDN on the Linux VM I decided to do the rewrites on. All my previous articles were on https://hammertime.tech breaking all of my links from places like Google and Bing, or even worse resulting in the dreaded SSL error.

Fast forward a bit to Cloudflare. In a previous life I used their free plan to protect against attack but that free plan also offers 3 free redirects AND a free SSL endpoint. This meant I could now redirect https://hammertime.tech to www. where my CNAME is setup for Azure Storage. It also meant I could redirect a bunch of my other domains like hammertimetech.com and have all my URLs work how I wanted. Nobody else will probably notice this.. but it’s one of those things I wanted in place - I am weird like that!

One of the things that I wanted to be able to do was setup a full CI/CD pipeline for my blog. As someone once said If it’s worth doing, it’s worth overdoing and it was in that spirit I configured Azure DevOps to deploy Hexo.

First off a short intro to Azure DevOps. Previously known as Visual Studio Team Services (VSTS) it is a service that allows you to manage code repositories, boards, pipelines (which we’ll cover here) and even test plans. You can also use Azure Pipelines with GitHub and while I did not do that here because I wanted all my repos to be private, there is no reason you cannot use GitHub as your source repo. Especially since two weeks ago they announced free private repos.

I had initially intended to publish this as part of my Azure DevOps entry, but it felt like it needed its own dedicated article. For my Hexo workflow I decided I wanted to use the Windows Subsystem for Linux from here on referred to as WSL. This works best for me because I am primarily a Windows user and I also have a fair bit of experience with Linux. Getting Started The first thing you’ll need to do is get Hexo configured locally so that you can generate the static content for later deployment, and also run your local server to test your content.

When the time came to relaunch my blog I spent a fair amount of time researching options. I wanted something that worked well for me that didn’t require too much infrastructure. I also wanted to keep costs fairly low and not take on a large monthly recurring cost.

• Ideally, I wanted static content that I could host in an Azure Storage account or some sort of static website hosting.
• I wanted something that felt comfortable for me. I spend a fair amount of time authoring articles in Markdown and it has really grown on me over the past few years.
• An application with a fair amount of plugin and theme options, I don’t really want to get involved in creating a custom template. A reasonably sized community was a plus.

I’ve been hearing about the eminent demise of on-premise workloads and “Private Clouds” ever since the Public Cloud became a thing. Most recently I’ve seen quite a few articles about how their days are numbered.

I disagree.

In my role as a Product Architect for Microsoft Hyper-V and Cloud Platform my team and I deal with traditional Virtualization but we also dabble quite a bit in Public Clouds, mostly Microsoft Azure. We try and make sure we utilize every service that we can to provide a streamlined product offering for our customers. So, I live in these worlds and often advise customers and architect environments that take advantage of both worlds. I’ll be speaking primarily from the Microsoft side of things.

First off private clouds still provide significant value and lower your overall IT spend. Your benefits include being able to fully manage your entire stack from the networking on up. You’re in control of the compliance and how everything operates. There are still quite a few reasons to use traditional virtualization for things like legacy workloads and most of all control. You also have full access to all the capacity you purchased up front, and when you aren’t using that capacity it’s available to you right away. It certainly is not hyperscale, but it is guaranteed capacity within your data center.

Public clouds are advancing at a rapid pace, in some cases new features are added hourly. They are starting to become MUCH friendlier to compliance requirements like PCI, FedRAMP and many others. And as a result, it is becoming more appealing to put your workload in Azure or AWS.