Google Cloud Run makes deploying serverless containers a breeze. It has a fully managed serverless version, which gives software scalability, high availability, and cost based on precise usage. Being serverless, there are no servers for you to manage. In addition to these awesome reasons, this post discusses 5 more compelling reasons to use serverless containers on Google Cloud Run for your next project.
Serverless pain points #
Function as a service (FAAS) has lots of advantages, still, there are some pain points too. A developer advocate at Google Cloud did a survey about Serverless pain points
. Below is a summary of the results as presented at a conference in 2019.
It is very clear that Cold Starts
and Vendor Lock-in
are the two big ones. In this post, later we will into how Cloud Run manages these two issues.
How I ran into Google Cloud Run #
A year back I was helping some master's students here in Sydney with a side project. I was mentoring them, guiding them to have a real-world project they could include in their resumes. For this project, we started using Google Cloud Platform, why? Because you get $300 free credit for a year :) simple. There are other Serverless container offerings like AWS Fargate and Azure Containers. I don’t think they are as good and as software engineer friendly as Cloud Run. In my opinion, Google Cloud Run actually brings serverless containers to the masses. Running serverless containers on Cloud Run is very easy. If you can dockerize your app, you can run it in a serverless way on Cloud Run on serverless containers.
I wanted to learn how to set up a Google Kubernetes Engine (GKE) Kubernetes cluster, so I teamed up with another DevOps Engineer and started to configure a Kubernetes cluster. As the app’s backend API was already containerized and GKE was managed K8s I thought getting a running URL would not take long.
To my surprise, it took us like 2 days worth of work just to get a working URL for that API.
Fast forward 2 months, the project didn’t really go as planned and the k8s cluster was stopped in Feb 2019. Then in mid-Apr 2019, I read news about Google Cloud Run being available. It promised HTTPs URLs for any container with a web server running on port 8080.
I thought let’s give it a try. To my delightful surprise, I could get a working serverless HTTPs URL for the same app in like 30 mins.
That just blew my mind and I instantly became a Google Cloud Run Fan. If you liked my story, in addition to the official guides/videos do have a look at the unofficial Cloud Run FAQ and the awesome Cloud Run repos on Github. I have also done a talk on Serverless Containers on Google Cloud run.
Google Cloud Run in the wild #
Hopefully, after the above story, you want to read more about why should you invest time in learning and using Google Cloud Run. After that half failed, a somewhat successful project I tried Google Cloud Run for another personal side project. That project was Nepal_News_En twitter account. It currently has ~11k followers.
This is a relatively simple project, it gets news about Nepal in the English language from 14 sources (both local Nepalese media and international media).
It collects the news from either RSS or scrapes the headlines where RSS is not provided.
Currently running with a cron(ish) setup the app gets ~1 request per minute including collection and posting to Twitter. This small app is hosted on Google Cloud Run and I am paying under $0.10
a month but bear in mind the requests are pretty heavy as it has to scrape and extract out news headlines then save it into a database. If you have more questions about this app comment below are contact me over email.
Of course, it runs on serverless containers. With the amazing and generous pricing of Google Cloud Run the app runs almost free of cost.
Reasons to use serverless containers #
As Cloud run is serverless you already have the advantages of a Serverless offering. In my opinion, the following are some more compelling reasons to use serverless containers on Google Cloud Run:
1. No need to learn a new framework/paradigm #
The first thing to distinguish is Function as a Service (FAAS) is only one type of serverless offering, Amazon S3 is a backend as a service and it is also a serverless offering. So, as we generally think FAAS = serverless. Going Serverless means to deploy a function to one of the cloud providers. This has its own strings attached, you have too many functions to manage, you need to think of how to manage a fully stateless function, etc.
Then you might need to learn a new framework like the Serverless framework to get the real value out of a FAAS.
With containers it's all gone, you are probably using docker containers already. Instead of deploying them on your Kubernetes cluster, you can just run them on fully managed Cloud Run and it works.
Another advantage of serverless containers is you are not locked-in
to one provider, as they are containers you can run them wherever you want. If you want to move some Kubernetes cluster in the future that will be an easy move.
2. Serverless containers can run any language/binary/framework #
Function as a Service(FAAS) have their own place and it gives you unprecedented abstraction like you don’t need to worry about OS-level issues or security problems. But on the flip side, you are confined to the given runtimes and allowed versions. For example, if you want to run Node 12/14 on AWS Lambda it is not possible out of the box. Let’s take this even further, what if you want to run Rust or Fortran :). You can’t do it.
On Google cloud run you can even run Fortran or Pascal if you want.
As long as it is a container and can expose a web-server on port 8080 (or any configured post) you can run anything you want on serverless containers.
3. HTTPs URL + custom domain mapping #
Configuring SSL is not an easy task, with Let’s Encrypt you can get a free certificate still you have to configure and install it well. HTTPs secure websites are important from every aspect, even for things like SEO.
Cloud Run gives you HTTPs URL as soon as you deploy your container.
As an added bonus, you can even map your own domain to the running set of containers.
4. Google cloud toolset at your disposal #
Google Cloud Platform, in my opinion, is the most software engineer friendly cloud platform of them all. You can build your containers with Cloud Build, push them to Container Registry for running them later as serverless containers on Cloud Run.
On top of it, you can even debug your application in production with Stackdriver debugger and get performance analysis with Stackdriver trace.
There is a profiler if you want to use and monitoring and logging too. You can use all of these tools very easily with Google Cloud Run. For my side project, I am using trace and debugger sometimes. Trace has been very helpful to know the execution times for the scrapers of the project.
5. Decreased go-to-market lead time #
Business value is the most important thing a software engineer can deliver. If you choose the latest language/framework and set of technologies but the business can’t earn money, you might have already failed. With serverless containers on Google Cloud Run you can focus solely on delivering the right business value to your customers and decreasing time-to-market.
You will not have to design and execute a full-on CI/CD pipeline and deployment strategy.
You can get your product to the hands of your customers much faster. Even if your product becomes a massive hit and garners millions of requests per day as you are serverless the cloud provider (in this case Google) is going to scale your apps for you (given they are stateless). So you as a software engineer can focus on solving business problems to make more money for the business with serverless containers doing their job well.
On a different note, do try this tutorial if you want to deploy a Node.js application to Azure.
Conclusion #
Vendor lock-in and cold start are the two major issues with FAAS serverless model. With Google Cloud run you don’t need to worry about both these big issues for serverless containers.
As its containers, you can move anywhere and with the concurrency model of Cloud run, the cold start problem is handled to a good extent.
With the recent feature add of minimum instances, you can even have a few containers running all the time (then it is not serverless containers anymore). If you are concerned about the cost at this point, you might want to read this comparison between Cloud Run and Cloud functions.
If you are convinced by now to use serverless containers with Google Cloud Run, take Laravel or Symfony for a spin. You can even try a simple NodeJs app if you like.
All of them have the Run on Google Cloud
button which makes deploying insanely easy. If you want to set up your CI/CD pipeline have a look at the cloudbuild.yml file in the Currency API NodeJs repo. For a general overview of serverless containers, please watch my talk.
All in all, if I start a new pet project or even a production load ready project today I will go with serverless containers on Cloud Run for sure.