Building a personal web service in Go, TDD Style: Part 3 - Dashed Dreams

Harsh realities and pivoting

If you recall from my first entry on this “artist tracker” service, part of my ambition with starting this project was to learn more about Google Cloud Platform, Kubernetes and other unfamiliar technologies. Now that I thoroughly understood my sample project and could deploy it locally, I wanted to experiment with Google’s cloud products and see which tools I might like to use. It would be so cool to have a managed cloud database like Google’s Cloud SQL product, I thought to myself. Well, it turns out it can get pretty expensive and it is not always clear how much it will cost. Granted, you can experiment in a free trial and get a sense of what your costs might be, but I was starting to get a healthy dose of sticker shock.

Kubernetes???

I set my eyes on Kubernetes. Kubernetes is a beast of a technology and it can be hard to understand without first-hand experience. I hoped that this project could be a way to shed some light on this mammoth technology. Sadly, it seems Google Kubernetes Engine (GKE) ain’t cheap either. My friend uses it to host some of our Discord chat bot functionality, as well as serve his personal website. While this is total overkill, he learned a lot in the process. From him, I learned that the price per month is a non-trivial expense. I want to learn, but I am also not keen on shelling out the big bucks for my toy web application. It was time to pivot.

Pivoting

I decided to look into deploying on my existing Digital Ocean droplet. Here, I host my LLC and game development studio’s sites, rozeblud.com and newhellstudios.com, via Apache HTTP Server. I made use of Virtual Hosts to run both sites out of the same cloud VM. Why not use this droplet for my new web application? Since I had my app running locally via Docker, I decided to try running this in my Droplet. I installed Docker and went to work and then… CRASH. Docker died, and a quick Stack Overflow of the resultant error demonstrated yet another harsh reality. My Droplet has half a gig of RAM and Docker needs considerably more than that to run without dying. Now it was time to solve cost-savings problems instead of my more grandiose initial dreams.

It ain’t pretty, but it works?

I finally got the app deployed directly, circumventing Docker entirely and deploying on the VM itself. However, since Apache had claims to my ports :80 and :22, I had to go with the old standby :8080. I was not sure if there was a way to get a nice domain to visit my app - instead I had to go directly to the IP address like http://123.456.78.9:8080. This works, and I am all about DIY solutions, but it still felt a little cheap. More than anything, I wanted to move on to my actual application development, so I shelved my findings and decided to revisit this issue at a later date.