Serverless on GCP comes in two forms; Cloud Functions and Cloud Run. Here are the key differences and here is why you should choose Cloud Run.
Cloud Functions
Cloud functions essentially work by uploading source code to Google. Your code is automatically build using Google Cloud Build into a GCP Cloud Function.
Your cloud function is executed on demand; it can be triggered by:
- HTTP
- Cloud Storage — files added to or deleted from buckets
- Pub/Sub — trigger your functions based on messages in pub/sub topics to develop a fully event driven solution
- Firestore — trigger your functions based on the creation, write or delete of records in your firestore cloud database. Firestore is definitely worth a look
- Firebase — trigger your functions based on various firebase events such as analytics and authentication (user create, delete)
Cloud Run
Cloud Run is based on Kubernetes and is essentially ‘cloud docker containers’ instead of cloud functions. You can choose whatever you like inside your container and your container runs when triggered.
Cloud run containers can be triggered by:
- HTTP
- gRPC — Cloud functions do NOT work with gRPC but Cloud Run does
- WebSockets
- Pub/Sub
- Scheduling
- Asynchronous trigger by Cloud Tasks
Pros and Cons
Cloud Functions can be triggered by FireStore events and updates to Cloud Storage whereas Cloud Run cannot. Cloud Run can be triggered by gRPC whereas Cloud Functions cannot.
With Cloud Functions, you are limited to Node.js, Python, Go, Java, .NET and Ruby. With Cloud Run, you can use any language and need only supply a container which responds appropriately to a trigger event.
Google recommends using Google Cloud Run for larger microservice setups as the concurrency available is larger than that provided by Cloud Functions. I would lean towards Cloud Run as it has greater flexibility with containerisation allowing you to use any language you like, not just those supported. Your code will also be much more portable — code for cloud functions has to be adapted to fit the Cloud Functions runtime — whereas containers for Cloud Run are equally at home whether running in Docker, Kubernetes or Cloud Run.
There are some triggers which Cloud Functions enjoy and are not available to Cloud Run — but don’t rule out the idea of having very small cloud functions which respond to a trigger by filing an event in a pub/sub queue for Cloud Run to pick up on.
My Conclusion
Having deployed both, I would definitely go with Cloud Run. The fact you submit a finished container to be executed gives you much more power over what you’re shipping. Speaking from a Go perspective, Cloud Functions don’t support modules sourced from private repos, and that can cause a lot of hassles, so another reason to go with Cloud Run.
When you consider that you can capture Cloud Functions exclusive triggers with a function and then immediately pass the event on to a pub/sub queue, it’s game set and match for Cloud Run.
