Who is your blogger and what does he do?

As a Cloud Developer Advocate for Microsoft, I enjoy spreading my love of really cool technology and how it can make everyone’s life easier. I’ve been meaning to get my blog back online for some time now as an avenue to spread that love, but it would always somehow end up on the back burner. “I don’t have time for that,” I’d lie to myself.

It was finally time for me to get the blog back together again. As I started to work on it, I immediately ran into a few questions that needed answering:

• What should I choose as my blogging software?
• Should I go with what is safe/known to me (WordPress)?
• Should I host it myself and build out the infrastructure via automation?
• Should I pay to host it on a PaaS (Platform as a Service) somewhere else?
• Could I easily automate the deployment and publishing of my blog posts and make it enjoyable?

Let’s back up for a second here.

In my past life, my blog choice was always WordPress. I’d done some fairly extensive work as a professional services consultant around WordPress including customization, migrations, etc. Any time I’d deploy WordPress, it meant a LAMP (Linux-Apache-MySQL-PHP) stack style setup, including all of the basic monitoring and maintenance that comes along with it – or a PaaS style offering where I could simply toss my document root up, set up a basic MySQL DB, set some connection strings, and go to work. This was so automatic to me by now that there were a few things I never thought about. Do I really need the extra weight that comes with WordPress? Do I need the heavier backend and control panel? The answers have always been a resounding, “no” – I just failed to ever ask myself those questions.

I was on auto pilot.

Even though most of my professional career has been around right-sizing and architecting the most appropriate solution to my customer’s problems, I would automatically default to what was easiest for my own deployments instead of looking at more appropriate solutions that I had never worked with previously. It was the path of least resistance, but also the path of least growth.

A little background goes a long way.

The bulk of the experience I have comes from the hosting arena. I’ve worked at some bigger players in this space (Rackspace, AWS) as a wide variety of different roles such as Monitoring Technician, Support Specialist, Linux Administrator, Senior Linux Lead Technician, Professional Services Consultant, Solutions Architect, DevOps Engineer, to name a few. I’ve been all over the map in terms of technical roles in my past 12+ years in the hosting industry, but one place I hadn’t ventured very far into was straight development work.

Working with infrastructure as code using tools like Puppet, Chef, Fabric, Terraform, Ansible, etc. has given me some great coding skills past the scripts that I’d slam out to cover a problem. It’s also given me one of the best mindset shifts I’ve had since I started working in this industry.

Automate all the things.

Before working with configuration management and infrastructure as code tools, I hadn’t really used Git much either, but it’s now almost second nature to me.

That said, I had never seen myself as a true developer. What does that even mean? I had written code, yes – but never as a frontend or backend developer on any kind of project. Given my roots in engineering, I’d always default to what is most comfortable to me. In the case of configuring my personal non-mission-critical blog, that would mean slamming out some infrastructure as code in a tool like Terraform to build out a LAMP stack, to set up monitoring, to drop the blog on it, and then I’d get to work. Definitely not the most direct method for the problem I was trying to solve, but the lowest cost to entry for my background and skillset.

I’ve gone rogue.

I’ve seen others hosting blogs on static site generating frameworks, but I had never really looked into them myself. Knowing the problem (needing a super basic blog) could be solved with this technology versus what I was comfortable with and used to, I decided to take the unknown-to-me plunge. After settling on this route, I solidified a few more requirements for this blog. I would:

• use version control
• automate the release of changes
• work toward making the blogging/deployment process super easy
• wrap the experience in some cool technology I’ve played with while working on Microsoft Azure
• create and post some content to spread the knowledge about how I did it (blogception)

🔥 Welcome to my first blog post on a static site generated by the framework Hugo! :D 🔥

The tutorial on how I set this up is currently in flight and will be posted soon, but this is what I have configured so far at a high level:

• Microsoft Azure App Services is being used to host this site (this can be free depending on your requirements!)
• VSTS (Visual Studio Team Services) hosts my git repo for this site (it’s free!)
• My VSTS and Azure accounts are linked for Continuous Delivery (a feature currently in preview) in Azure App Services
• VSTS handles my CI/CD (Continuous Integration/Continuous Deployment) directly with Azure App Services
• When I push changes (new blog posts, for example) to my code repository’s master branch, VSTS builds and deploys it via Continuous Delivery (in preview)

That’s great and all, but what does this mean?

What it means for me is this is the simplest blog I’ve ever set up and will be the simplest blog I’ve ever maintained or created content for. I am quite literally only maintaining my code repository which is primarily the blog posts I will be making in the future. The workflow looks like this at a high level:

• I work on my blog posts locally
• I have Hugo generate the new static content locally
• I test it locally to make sure it looks good
• I commit and push those changes to my repository
• VSTS takes over and builds and deploys my changes
• My new changes are live within seconds

It really is as simple as that. I am going to iterate on this solution and look at adding things like SSL, CDN, a staging environment (not really needed for my purposes being I can see how things look locally before I push, but I’d like to look into it anyway), maybe even some rudimentary testing (not super important here, but why not). I also want to look at having Hugo build the static content as a part of the CI/CD process versus me building it locally. I know this won’t make much of a difference in terms of speed, but I am interested in figuring this process out as well.

I know this is a lot of words. If you’ve made it this far, thank you! I will have tutorials coming in short order on what this build out looks like on VSTS and Azure App Services, so stay tuned!

tl;dr me, please.

I’ve always defaulted to the path of least resistance for creating and running my own blogs in the past. I decided this time to learn and spread the love while doing it and chose to host this blog on a new-to-me technology of static site generation using the Hugo framework running on Microsoft Azure App Services coupled with VSTS. I’m totally digging it, tutorials coming soon.