One of the reasons I outlined in my previous post on why I’ve decided to move from my personal WordPress installs to a static HTML site was the cheapness in hosting static sites on services such as Amazon S3 and Google Cloud Storage.
Before Google Cloud Storage came about Amazon S3 was the standard. People tried hosting their static sites using Dropbox’s Public pages but this ended up being more cumbersome. Initially when I ventured into the static space a couple of years ago I tried Amazon S3 with one of my sites.
The experience was okay, but it didn’t eventuate. I found at the time the service Amazon offered was great, but the managing of the content a little too difficult.
Today though I’ve decided to use Google Cloud Storage as my main hosting provider. I’ve never used them before and as they were slightly cheaper than Amazon I thought to give them a try.
So far so good. I’ve used their command line tool
gsutil to help upload, sync, and delete buckets, and it’s all gone without too much of a hitch.
(I’ve found that for
gsutil to work on my Mac I have to
source .bash_profile – I’ve followed Google’s instructions on getting it all setup but have had to apply that tweak to get the utility working)
Anyway, the reasons for why I’ve decided to use Google Cloud Storage for storing my old-WordPress-new-static websites is:
- Cost. Although not by much, Google has beaten Amazon in this space by four-tenths of a cent (at least as of today).
- Command line utility. The command line utility and documentation provided by Google was very clear and understandable. The
bash_profileissue above everything else has gone seamlessly.
- It’s Google. Sorry Amazon, but Google have provided a LOT of traffic to my sites throughout the years therefore I’m quite comfortable and trusting in this area with them. Don’t get me wrong I’ve used Amazon’s web services too, and they’ve been great, but Google has given me free traffic.
But why not store them on your current web server?
This was a question I had contemplated. I even thought about version control with installing git on the server and enabling the server to sync with changes on the local machine. The only advantage I could see was the granular controls and tweaks one could do on their nginx server serving the pages (even routing pages to their new destination now pages have a “.html” extension), the disadvantages were with the higher costs (although paying $5/month with Digital Ocean for an Ubuntu instance certainly wasn’t breaking the bank) and maintaining the server.
I’ll certainly keep this idea as a backup, should Google Cloud and S3 prove too difficult, but let’s see how we go without needing to maintain a server.
The main reasons for not choosing either were that I had more than one personal site that I was moving across and both providers only allow one free site per account – and maintaining more than one personal site from several GitHub accounts wasn’t too appealing. I could have chosen to move to a paid plan but this ended up being the most expensive choice out of the lot. I do like git and version control though – so it certainly was very tempting! At this point in time though not today.
Again it’s important to look thoroughly into the static service providers you’ll be using for your sites if you’ve decided to migrate from WordPress to a static setup. My needs for my personal sites aren’t that great and because I’m not relying on maintaining a living through these changes then my requirements are not as extensive as perhaps yours might be. Look at all the alternatives and don’t be afraid to test them out.