Google Cloud Run makes deploying stateless containers a breeze. It has a fully managed serverless version, which gives huge scalability, high availability and cost based on precise usage. Being serverless, there are no servers for us to manage. In addition to these awesome reasons, this post discusses 5 more compelling reasons to use Google Cloud Run with serverless containers for your next project and it just became generally available.

Serverless pain points

Serverless Function as a service (FAAS) has lots of advantages, still, there are some pain points. Bret McGowen (a developer advocate at Google Cloud) did a survey about Serverless pain points. Below is a summary of the results (as presented at Serverless Conf 2019 NYC by Bret)

Serverless pain points as per a survey by Bret

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 Masters 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, still, I don’t think they are as good and as software engineer friendly as Cloud Run.

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. 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.

Google Cloud Run in the wild

Hopefully, after the above story, you want to read more about why should I invest my 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. This project is 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 $2 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 twitter/email.

Reasons

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 Google Cloud Run:

1. No need to learn a new framework/paradigm

The first thing to distinguish is Function as a Service (FAAS) 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 Serverlss framework to get the real value out of a FAAS. With containers its 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 is you are not locked-in to one provider, as they are containers you can run them wherever you want.

2. 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 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 you can run anything you want.

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. 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 lastest 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.

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. 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. 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 Cloud Run as it has just been generally available.

Originally published at https://geshan.com.np on November 17, 2019.