Having spent quite some time over the last few years using Amazon Web Services (AWS), I’ve decided I should get to know some of the other cloud platforms. So I set out on an experiment to get something up and running on Google Cloud Platform (GCP).
An important aspect to consider is that FLXS is very much a side project for me at the moment - pretty much just a minimal holding site. It gets virtually no traffic, so I want to keep costs as low as possible.
With this in mind, I am aiming to “serverless” the living daylights out of as much as possible so that I can take full advantage of “The Cloud” and only pay for what I am using.
1st Deployment: London, UK (europe-west2).
The application is packaged into a 76MB docker image and uploaded to GCP Artifact Registry. As a bonus, 76MB keeps it well under the free-usage tier. :-)
This makes it really simple to get it up and running using Cloud Run. The console gives you a nice GUI to choose the image you want to deploy direct from the Artifact Registry; give it a name; pick a region and tick a few boxes box to say it’s public and should allow unauthenticated requests.
Within a few seconds the app is up and running and accessible on a domain name such as https://prod-website-wy53m3v3ra-ez.a.run.app.
This domain name might be OK for a back-end service that no one would ever manually connect to, but for a public endpint this needs to be on a custom domain - in this case flxs.co.uk.
Google offers three possible solutions for using custom domains with Cloud Run. Which are:-
- Use a global external HTTP(S) load balancer
- Use Firebase Hosting
- Use Cloud Run domain mapping (Limited availability)
Indeed, No.3 is not available in the London region, so I went for option 1 - a global load balancer. Sounds fancy!
By Googles own blog article on the subject, setting this up is not easy and involves quite a few components that all need hooking together. Thankfully, they also have a terrform module which provides a much simpler way to get it all working. After a little bit of terraform scripting, I had it all deployed and working. Success!
A few days later, I checked on the billing dashboard in the cloud console:-
Although the costs for the 5 days highlighted is only around £0.50/day, I know that there were maybe 1 or two requests to the site - so I had missed my target of only paying for what was being used.
This was my fault for being too quick to assume I would only be billed for requests made through the load balancer, when in fact, there is a basic minimum charge just for having a Global Load Balancer configured in GCP.
Time for plan B.
2nd Deployment: Eemshaven, Netherlands (europe-west4)
Of the two remaining options, Firebase Hosting seemed like it was just putting something else “in-front” of my app, and could end up being another cost that creeps up.
I looked into the “Limited availability” for Cloud Run domain mapping, and found it was available in another european region. Given how simple it was to deploy the app in the first place, I chose to just delete everything I had deployed so far and re-deploy in the Eemshaven region but replace the Global Load Balancer with Cloud Run domain mapping.
It’s important to note that Cloud Run domain mapping is a preview feature (probably why it is not available in all regions at this time).
No only was this actually much simpler to deploy than the load balancer version, but as the graph shows we have virtually zero charges from Cloud Run (for our virtually zero requests to the website).
The blue blocks on the graph are the £0.02/day for using Cloud DNS.
I did some basic latency checks to the two regions from my home broadband connection, and there was no significant difference between them for this use case.
3rd Deployment: TBC
While digging up all the URLs I have read over the last few weeks for this article, I also dug up another one from Reddit.
The author of that comment says they are the PM for Cloud Run and goes into some details about the various domain mapping options for Cloud Run. It’s possible that the simple domain mapping functionality will never make it to GA status and I might have to re-deploy again using the Firebase option (Which does have a free tier for a simple use case such as this).
As the saying goes, “there are many ways to skin a cat”, and I think that is very true in Software development and Cloud Computing. This kind of experimenting of different ways to achive the same result is pretty much what FinOps is about:-
FinOps is a public cloud management discipline that enables organizations to get maximum business value from cloud by helping technology, finance, and business teams to collaborate on data-driven spending decisions.
By comparing the data (low latency difference, low number of site visitors), I made the decision to move the deployment to a different region and benefit from a much more cost-effective solution.
Although the Global Load Balancer did allow me to use my own domain name, it was a classic case of cracking an egg with a sledgehammer. It’s a very capable and powerful offering - I just dont need that kind of functionality (yet).