Ten years ago, May 14 2005 specifically, I started this blog on the WordPress platform. I chose WordPress for a number of reasons, but the primary reasons were that it was simple - really simple - for me to get up an going and that the hosting providers I was considering supported it. I wanted to use the web, but not actually develop for the web. WordPress seemed like the right choice. I did consider other options, and every few years, I would look around at what else was available. I have played with Drupal, Joomla, DasBlog, and others I can’t remember. In the end, I always ended up back on WordPress. Why - simplicity. It did what I wanted.
Time passes and things change. I don’t have the worlds largest blog, only around 80 posts or so from those 10 ten years, but my WordPress installation was loaded with plug-ins. I had plug-ins for SEO, Analytics, Facebook cross-posting, Twitter cross-posting, CAPTCHA, social media, and more. Worse, I was actually starting to manage the site. WordPress, plug-ins, and themes would all have different update schedules. This meant that I needed to deal with updates more than just once in a while. It also meant that very often, I would find that my blog has some PHP error codes displayed on my home page. In the end WordPress was no longer simple.
I still stayed, because it was fast, and because my blog writing software of choice (Windows Live Writer) supported it. The problem is that it is no longer fast, and WLW is effectively abandonware. It hasn’t been updated in years, and the last glimmer of hope, Windows Live Writer going Open Source?, seems to have not materialized.
Time continues to pass, and I find myself spending more time with web development and the cloud. I decide to try an experiment and host my blog on my cloud provided host. So out comes my favorite tool, Google, and I search for WordPress on AWS and Azure. I decide to try an experiment and set up WordPress in Azure. I chose Azure since I happened to have some unused free usage there, and I have done some playing in the AWS space already. I figured it would be a good way to learn more about Azure.
The Azure Marketplace has thousands of prepackaged deployment options, and given that I refused to setup WordPress from the ground up, it was my starting point. A quick search on WordPress later, and I see the following options:
Two real options here - WordPress or Scalable WordPress. I should point out that the same search on the Azure website produced more results. The problem is that only first two choices above were Web Applications, which meant I would not have to deal with virtual machines. I had no desire to manage a Linux server, MySQL database, WordPress, and a VM. So Azures Web Application was a requirement. So which one to use? Easy - whichever one is cheaper. So here are some prices.
Scalable WordPress Pricing Tiers
WordPress Pricing Tiers
Given that my current WordPress hosting provider is costing me around $15 / month, I wanted to try and find similar, and on the cloud, that meant a D1 or F1 plan. Either that, or I need to rethink the economics of my cloud usage. Scott Hanselman blogged about cloud economics in Penny Pinching in the Cloud: When do Azure Websites make sense?. Without going too deep into it, the B1 makes sense only if I can host 4 websites like my blog, and the S1 makes sense only if I get to 8. The D1 makes sense per website, so long as shared can handle the load, and only until I hit 6 websites. At 6, I should move to a B1, at 8 the S1. However, not much of that matters. I have a block of free dollars per month that is large enough to cover an S1. While I considered the economics, it was more about finding out how much box I needed to make my site hum along. The one economic choice I made is to not use the Scalable WordPress option since it had a minimum of an S1 box.
Starting with WordPress on an F1 was easy enough. I followed the Azure Marketplace work flow and the site was soon created. One catch. WordPress required MySQL, and there is no option for MariaDB yet on Azure. That meant another $10 / month on top of whatever pricing tier selected. Given my free dollars, this was not a show stopper, but it did annoy me. MySQL can be provisioned for open source, and I didn’t need my blog running on a mission critical build out.
Fast forward a few days of tinkering, and I finally get the whole thing set up. Problem is - performance. It sucks. No. It is far worse than that. Just trying to configure the plug-ins or load themes was painful. So, employing the beauty that is the cloud, I upped my tier to B1. It improved from horrible to just terrible. I played with options. Did some more Googling, but unless I put more horses under the hood, this was the best it was going to get. I want to be add. The performance was not just horrible in administrative mode, it was bad as a reader of the site.
I spent more time on plumbing than I wanted. Time to look elsewhere.
{:.float_right}My next stop along the cloudy blogosphere was Ghost. I support Ghost as a Kickstarter project, and really liked the back to basics model it was taking. Once more I searched the net for others breaking this ground before, and once more, I found a Scott Hanselman article to leverage - How to install the nodejs Ghost blogging software on Azure Websites. A few days of effort pass, and the result - no joy. I just could not get it working right. It was little issues here and there; all for another days post. The result is Ghost wasn’t going to be my platform.
{:.float_right}However, the effort with Ghost was not wasted. During my research and efforts, I learned about a whole class of static web site generators. I heard bits and pieces about them before, but never paid any real attention. This time I did, and long story short (too late - I know), I settled on Jekyll. MiddleMan, Pretzel, and Hugo were close contenders. The support for Jekyll on GitHub meant there is a lot of information available for someone new. This makes it a great starting point into the static code web site world. The others I tried were not hard to work with, but Jekyll just had so much more available to learn from, that it is a great first step into this space. After porting my 80 or so posts, few pages over, and core functionality, I can see / feel some of the limits of Jekyll. However, I have been able to address my needs - at least for now.
So thats the story of how I got to Jekyll as my choice. I plan to blog my journey to make my new blog as functional as my old one was. Specifically, I had the following set of features that needed to exist to be able to claim success:
- All my posts must be ported, and look reasonably close
- All my posts must have the same permalink structure so that no ‘search memory’ is lost
- All of my post comments must be migrated
- There must be contact form
- It must support a Link Post Format
- Must support analytics
- Must support source code syntax highlighting
- Must support social sharing functions (Facebook, Twitter, and Email at the minimum)
- Must have social follow me functions (RSS/ATOM, Twitter, GitHub)
- Must have related post functionality
- Must have paged and previous / next post navigation
- Must support post to Twitter
Those were all features I used in WordPress, and whatever I moved to next, should support them. I was able to make Jekyll do all of that, plus some new functionality. In following posts, I plan to document how I solved some of these issues, and even a new Jekyll plug-in I had to write to do it.
Have you dealt with similar blog migrations? Do you have opinions on Jekyll or other static site generators? Let me in the comments below.