In 2020, the web is still the most accessible permission-less platform. For the past few months, I have been playing and building side projects to simplify my life. I started with a Calendar Bot for scheduling events, DeckSaver for downloading decks from Docsend, AutoSnoozer for email management, and StayInTouch for maintaining follow-ups.
When I started on this journey, I had the following in my mind.
- Cost of domain ~ 12$ a year or 1$ a month
- Cost of a VM ~ 10$ a month
And this is excluding maintenance efforts like TLS certificate renewal, server uptime, etc. I quickly realized that this isn’t sustainable. A single project would cost ~150$ a year to run. Add a few more side-projects, and this will be a costly hobby.
To avoid the domain costs, I deploy almost all of my side-projects as a sub-domain of my existing domain ashishb.net.
For compute and storage, I looked for alternatives. Few alternatives like Firebase Cloud Functions or AWS Lambda look great on the surface, but there is a considerable lock-in involved. Searching further, I found Google Cloud Run. It has zero base cost and zero lock-ins since it runs docker images and minimal configuration work. Cloud Run is serverless. The service deals with the task of getting and automatically renewing TLS certificates as well as scaling instances based on the demand. You get StackDriver logging for free. As there are no VMs, I can’t SSH into the machine and make changes, which is excellent from a security perspective since there is no chance of someone compromising and running services on it. I have to upload Docker images, so I get an added discipline of building fully portable docker images, which, if required, can be moved elsewhere with zero portability cost. Now, docker images are stateless, so, for storing data, I could have either used Google Cloud SQL or Google Cloud Storage (the equivalent of Amazon S3). The base cost of Cloud SQL is high ~20-30$ month, while it is zero for Cloud Storage. So, my current architecture consists of Google Cloud Run + Google Cloud Storage. Now, since Google Cloud Run keeps these Docker containers on standby, keep the container image size small to ensure quick bootups (cold starts).
Persistence and Secrets on Google Cloud Run
There are two issues to consider when deploying docker images. One is persistence, and the second is credentials (secrets). I like the zero base price of Google Cloud Storage (GCS), and that’s why it is my favorite for persistence. For storing credentials, say GCS read/write credentials, it is best not to store the keys in the docker image itself. The way I prefer to do is to pass them via Environment variables at the time of deployment. An even better approach for projects with multiple contributors is to use Secret Manager.
I mostly write in Go. I think it is a perfect language for building web services. That fact isn’t surprising when one realizes that it came out of Google, a company initially built around web services. I templated out my setup for faster iteration. It’s open-sourced at https://github.com/ashishb/golang-template-repo.
Deployment
To deploy to Google cloud run, first install gcloud CLI and do a one-time configuration.
|
|
Now push your image to Google Container Register. If your project ID is first_gcloud_project-67
and the service name is hello_world
then the tag name has to be gcr.io/first_gcloud_project/hello_world:main
|
|
Now, start your binary.
|
|
And your service is ready to be accessed. You can see the deployed URL from https://console.cloud.google.com/run?project= first_gcloud_project
Now, the service would be accessible at an unmemorizable .app domain. I would recommend mapping a more memorizable custom domain you own to the same service.
I have abstracted out all these steps and the ones mentioned in the previous blogpost into a single template repository.
- Clone the repo
git clone https://github.com/ashishb/golang-template-repo
- Fill in
GOOGLE_CLOUD_PROJECT_ID
andGOOGLE_CLOUD_RUN_SERVICE_NAME
- And deploy it using
make gcloud_deploy