Hosting a Discord bot on Google Cloud

In my previous post I mentioned the ongoing issue of yfinance and why I wasn’t able to use Polygon API as alternative for yfinance . The tl;dr is Polygon doesn’t provide real-time pricing data for free. I don’t have any problems with that but I also don’t want to clutter my code with unnecessary dependencies that it doesn’t need, so I removed the integration with Polygon API in this commit.

From the beginning the reason I wanted to build the bot is mostly educational. If things don’t work out because there’s no API available at a reasonable cost to me then I’m not going to lose sleep because of a broken bot. What makes me lose sleep at night (and day) is having the bot’s Python script running in my personal laptop 24/7.

Ideally the script should be cloud-hosted and running from there but I haven’t done that yet. One reason is because I haven’t managed to find a time to do that. Another reason is probably due to the Paradox of Choice. While there is no shortage of cloud hosting services available on the Internet, it’s not always easy to pick up one that reasonably satisfies the budget and the quality of service (availability, reliability, etc.).

Cloud computing as its finest!

The most natural approach of not running it using my machine is to use a different machine that is up 24/7, then to have that omnipresent machine pull the code from Github and execute the script. There are 2 options that I had in mind: GCP Compute Engine and AWS EC2. In the end I opted for GCP because of … favoritism (I’m an ex-Google employee, i.e. a Xoogler).

From there the rest of the task is very straightforward

• Open GCP website and login with my Google account
• Go to the Console and start creating a VM instance. I chose an ec2-micro machine to take advantage of the pricing plan for GCE free tier
• SSH into the machine once it’s up and running
• Configure git and clone the stonk-bot repository from inside the VM
• Setup Python and the virtual environment
• Activate the virtual environment
• Execute the script
• Run the script, and here we go again!

What I enjoyed from this experience

The SSH-in-browser feature provided by GCP is amazing! It really reminds me of the days when I worked from home using a Google-issued Chromebook to SSH to my desktop terminal in the office. Back in the day working from home permanently wasn’t a thing yet but I travelled quite often and I had with me was a small and lightweight Chromebook. The Chromebook had no fancy pieces of software installed apart from the Chrome web browser (surprised!). No source code is allowed to be downloaded into the machine and engineers are supposed to SSH to their desktop terminal that sit in a Google office. The great thing about Google’s internal infrastructure is that most of the time people don’t really feel like they are having an SSH connection to a remote machine, which is the kind of experience I had with the SSH-in-browser tool today. I’ll should probably check how the experience with AWS sometime in the future.

What I learned from this experience

While the task seems to be straightforward there are always things to be learned along the way.

1. Choosing the right OS version: at first I chose a pretty old version of Ubuntu (Ubuntu18). As a result, the VM came bundled with Python 3.6 and I ran into issues with installing the dependencies using pip install -r requirements.txt that I didn’t have on my personal laptop (a Macbook). I then deleted that VM instance and created a new one running Ubuntu 22. The bundled Python version is 3.9 and I had no issues running the pip command to install the requirements.
2. Google Cloud Shell is ephemeral: on GCP when one can click on the Activate Cloud Shell button, a VM will be quickly provisioned and the user will be left with a terminal where almost anything with the VM like they normally would a GCE VM. Be careful! If you want to use the Cloud Shell’s VM to run a script that is supposed to be available 24/7, this is NOT the right option. First, the script will stop running when the shell is closed. Second, even if you leave the shell to be open 24/7, the SSH connection will time out and terminate the execution of your script.

What I think GCP can improve on from this experience

Dark mode and I can’t emphasize this enough! It doesn’t seem possible to switch the UI to dark mode to me so if it is already possible to do that, GCP needs to make that more visible on the screen.