How it started vs. How it's going - www.benrowland.net

Too long ago in 2004, this website started. I vividly recall the satisfaction when I typed www.benrowland.net into a browser, and it worked. I ran the website on Tomcat running in a DOS window on my Windows desktop, so it wasn’t quite a production-grade deployment. I had pointed my domain name to the IP address allocated to my home computer by my ISP, and there was something magical about watching the internet routing happen the way I’d hoped it would.

But I was more interested in learning about software development than having a stable website, so sometimes the site was up, sometimes it was down, and sometimes half-way inbetween.

Self-hosting taught me a lot. One morning I checked the site, and saw a big angry error page. By this point I was running Linux on my desktop computer, and at some point I’d upgraded and selinux had been activated without me knowing at the time. This is effectively an internal firewall, and was blocking communication between the Apache web server and the Tomcat back-end application container. This sort of thing would happen a lot. Something would go bump in the night, I’d wake up to an error page. I’d Google the error and troubleshoot just to get the site running again.

I was also running an SSH server which allowed me to log in to my computer from anywhere on the internet. This meant there were continual attempts to log in from random hackers all over the world. Of course, I had a secure password so none of these attempts succeeded. At first, I worried about these attempted hacks until I learned this is completely normal, and expected to happen - hackers will port-scan an entire IP range looking for an open port 22, and they will script login attempts using common bad passwords in the hope to find some low-hanging fruit. My logs would be filled up with these failed login attempts until I learned the best practice - use key-based authentication and disallow password logins.

Eventually, the continual trouble-shooting became too much (as well as the need to leave my noisy desktop computer running 24 hours a day). I took the plunge and signed up for a hosting plan. Now my website was running in a datacentre somewhere, instead of under my desk. But this turned out to be expensive - hosting plans which supported Java applications were more expensive than the Apache/PHP alternatives. I’m not sure why - perhaps the additional memory usage of Java web application containers meant less customer deployments could run on a single host.

The cost commitment became hard to justify so I cancelled the plan. I think this website was unavailable for a long time, though of course I still had ownership of the domain.

Things came around again later on, and I got interested in self-hosting again. This time, using a small net-top mini computer which was effectively silent. At this point, I’d gone to Wordpress as a platform as it was much more flexible and secure than my hobby application, and I didn’t want to spend all my time maintaining my own blogging software. This was a great way to learn about containerisation. I was running CoreOS which is designed for hosting containers, and was experimenting with running different domains within different containers. I used Nginx Reverse Proxy to route different subdomain names to the appopriate container, each running an Apache instance with a matching virtual host. This spawned an interesting deep-dive into traffic routing with Docker, such as how to serve the front- and back-end of an application from different containers.

For one reason or another, that particular journey lost momentum and the site was undeployed for another year or so. As of sometime in early 2020 the needle has swung back towards using a hosting provider, and this time it’s Google Cloud. The site is now generated using Hugo site templates. This more closely matches my intentions for the site at this time - relatively simple content with no need for the features Wordpress provides. Wordpress attracts hacking attempts as it’s a very popular platform with known administration endpoints, and so there’s definitely a need to follow software updates carefully, as security holes get fixed. Not so with Hugo, as you generate a static website offline from Markup, using some Go scripts.

So now, the site is deployed to a Google Cloud Bucket, which is effectively like Amazon S3. Up until recently there was no HTTPS support, and this was because my domain name was just a CNAME pointing to the GC bucket domain which the content was hosted on. HTTPS connections were not supported by this method, and it took me a little while to figure out how to do it.

At first, I thought I needed an additional CloudFront deployment in front of the GC bucket - this sounded like overkill for what I really needed. Fortunately, I searched again more recently and found that you can easily solve this problem in the Google Cloud UI. You set up a front-end HTTP load balancer with a static IP address, and also a HTTPS front-end which redirects to the former. You then provision a SSL certificate - also easy enough to do within the Google Cloud dashboard. The HTTP front-end can then be pointed at the existing back-end cloud bucket.

This isn’t supposed to be an advert for Google Cloud, and indeed there is a downside - there are ongoing costs with this approach. There’s a “Global Forwarding Rule Minimum Service Charge”, which works out at maybe £10 or so per month. It can be a bit hard to figure out up-front what your costs are going to be with Google Cloud, but I’m not surprised there would be some sort of cost associated with a permanently allocated static IP address. You need one of these as you need something permanent to point your domain A record to.

Technically though, you aren’t charged for a static IP address as long as it’s attached to a global forwarding rule, but you do pay for that! You’re allowed up to 5 global forwarding rules with the same minimum cost, so I’m at the worst-case for utilisation right now. Ideally, I’d find a reason to set up 4 more domain names under the same account, and it would cost the same as I’m paying now. The alternative is something like Amazon’s Route 53, which dynamically resolves domain routing to changing IP addresses. That’s an option to look into later on - I have played around a small amount with AWS but never deployed anything yet (outside of work).

I don’t think this setup on Google Cloud is too bad. Hopefully I have room to do a lot more without additional cost. I could set up a few more back-ends on their own domains, perhaps even running some fuctional apps. I have an application I’m working on to track daily activities, and eventually I want to deploy this somewhere - but that’s for another post.