Main Components:

• Cloud Provider – Google Cloud Platform
• DNS – Cloudfare
• Infrastructure Management- Terraform gitlab project
• Container Orchestration (Google Kubernetes Engine)
• Ingress controller – Nginx how-to
• CI/CD pipeline: Gitlab)
• Static Content Serving: GCS
• Blog/CMS: WordPress

Design Philosophy

The aim of this website is to provide both a platform for testing software and techniques as well as to provide some practical examples of working code. With this in mind the site and the code surrounding it is designed with the following aims:

Minimal operational work

I like coding. I like figuring out how to break down a problem and solve it. I like writing efficient code. I’m not particularly enamoured with setting up servers manually or configuring networking between them. In order to avoid too much of this, where possible I’ve used things like Kubernetes to manage the servers underlying this site. In combination with using pre-emptible servers (googles spare capacity) this brings the cost of this site down to about $7 a server as compared to $20-odd dollars a server to reserve one for sole use. This and autoscaling of workloads keeps the running costs of the website and all servers below 30 pounds or so a month.

I’ve used gitlab to automatically package and deploy code, and I’ve used docker and avoided persisting data to containers where possible so that I can be relatively chilled about this site and know that if something falls over it will detect it and fix itself and bring itself up again in the same state as before. One tricky bit that ate a bit of time was configuring this WordPress site to install my desired plugins automatically (link writeup here)

Be cheap to run

I don’t have the budget of an enterprise but I also don’t have the worries of developer costs in terms of spending a bit more time configuring and setting things up. The cheapest set up I’ve found that combines both a well managed kubernetes set up and relatively hassle free ability to scale things is googles offering of Kubernetes in one zone for free. The other part of this is I lean pretty heavily on pre-made modules from the likes of bitnami using their wordpress docker images to do the gruntwork of setting up wordpress.

For even bigger savings I could also use the nginx ingress to route your requests through to external servers running on even more budget providers like hetzner where an equivalent server to a google server is about 30-50% of the price. E.g at the time of writing this I currently run the site on n1-standard-1 google pre-emptible servers using googles spare capacity (aka my applications get kicked off onto other servers frequently). This costs me $7.30 a month as of 07th June 2020. Contrast this with hetzner where a roughly equivalent 1GB ram server costs $2.96

Have code be as publically available as possible

One of the things I’ve always found useful as a learning resource is working code bases with accompanying write-ups. There are a lot of tutorials on the internet that are out of date or for various reasons cannot be proven to work. There are also many working codebases at many companies, but a majority of them are locked down for commercial reasons or are so low level that they’re of less use to someone starting out. I try to keep the code behind this site and its applications in gitlab as much as reasonably possible so that if you are interested in having a working example then it will be available to lookup in gitlab.

Be as self healing as possible

When running applications there is a 100 percent certainty that an application (of which this web page you are looking at is one) will eventually go down, or even more fun, be taken out by networking changes or application changes etc. Rather than trying to achieve the impossible of 0 breakages, it’s normally less painful to accept things will break sometimes and spend your time building things such as the application can rebuild itself rather than having an intricate manual set-up process that you have to repeat whenever things fall over. Another key part of this is using immutability so things can be rolled back as much as possible and anything deployed will deploy the same next time if the server is destroyed or some other component breaks.

A dirty little secret of this website. Due to the nature of using spare capacity servers (aka “preemptible” servers on Google Cloud). All of the servers are killed randomly at a maximum interval of 24 hours. Whenever this happens the application needs to re-appear on another server fully formed ready to receive requests from you without any manual intervention (e.g manually input IP addresses of the new server box).

Improvements

Using wordpress to act as the core CMS for writing the website allowed me to get things up and running as quickly as possible in terms of writing and uploading content as well as being such a ubiquitous platform that there are plenty of plugins and instructions available for it. Say if I had the use case of providing more content to mobile phones or multiple device types. I would take a look at a headless CMS and use react to create a frontend for the content.