GCP – Three ways of receiving events in Cloud Run

Cloud Run and Eventarc is a great combination for building event-driven services with different event routing options. There are two trigger types (Audit Logs and Pub/Sub) to choose from in Eventarc. Eventarc uses Pub/Sub as its underlying transport layer and provides convenience and standardization on top of it. If you wanted to, you could skip Eventarc and read messages directly from Pub/Sub in Cloud Run. 

This blog post details three ways of receiving events in Cloud Run and provides a decision framework on how to choose. 

3 ways of receiving events

The three main ways of receiving events in Cloud Run are:

1. Audit Logs via Eventarc
2. Pub/Sub via Eventarc
3. Pub/Sub direct

Option 1 is for the 90+ Google Cloud services that support Audit Logs. Eventarc reads those Audit Logs, converts them to CloudEvents, and sends them to Cloud Run services. See this guide for more on how to receive Cloud Storage events via Audit Logs using Eventarc.

Option 2 is for custom applications or Google Cloud services that have a Pub/Sub integration. Eventarc reads messages from the Pub/Sub topic, converts them to CloudEvents, and sends them to Cloud Run services, as shown in this guide. 

Option 3 is also for custom applications or Google Cloud services that have a Pub/Sub integration. Instead of using Eventarc, you can have Pub/Sub directly HTTP push the Pub/Sub message to the Cloud Run service, as shown in this guide. 

Decision framework

Given the three event routing options, how do you decide which one is best for the service you’re interested in reading events from? Here’s decision framework to help you decide:

The reasoning behind the decision framework boils down to answering these questions: 

1. Does the Google Cloud service or application support Audit Logs, Pub/Sub, or both?
2. When both Audit Logs and Pub/Sub are supported, does the Audit Log entry have more or different info than the Pub/Sub message or vice versa?
3. In the Pub/Sub case, do you care about standardizing on Eventarc and CloudEvents format and the convenience of not having to create Pub/Sub topics and subscriptions?

Let’s explore these questions with some concrete scenarios. 

In the custom application scenario, there are no Audit Logs because it’s not a Google Cloud service, so you only need to consider Pub/Sub options. The question then becomes whether you want to get Pub/Sub messages directly or via Eventarc. Pub/Sub is probably the more familiar route whereas Eventarc provides a standard way of receiving events from multiple sources and a standard CloudEvent format. This is useful if you intend to read from multiple event sources and not just from Pub/Sub.

If you want to read events from a Google Cloud service that supports only Audit Logs, then your only option is Eventarc. 

It becomes more interesting when a Google Cloud service supports both Audit Logs and Pub/Sub (e.g., Cloud Build, Cloud Storage). In these cases, the type/content of Audit Logs and Pub/Sub messages should drive your choice. 

For example, Cloud Storage can generate Audit Logs and it can also send a message to a Pub/Sub topic when a new object is created. The contents (bucket name, object name) and latency of both are roughly the same, so you can choose either.

Cloud Build can also generate both Audit Logs and Pub/Sub messages but the Pub/Sub based build notifications have build status (success, failure) whereas Audit Logs of Cloud Build mainly provide info about admin operations such as build creation and deletion. If build status is important, it makes sense to choose Pub/Sub over Audit Logs.

In both Cloud Storage and Cloud Build, if you go with Pub/Sub, you still need to decide whether you’ll read them with or without Eventarc. As already explained in the custom application scenario, this is a choice between a familiar setup with Pub/Sub vs. convenience and standardization that comes with Eventarc and CloudEvents. 

I should note that Eventarc aims to improve upon its event sources and contents of events in future iterations. You should expect to see richer events beyond what Audit Logs provide today.

As always, feel free to reach out to me on Twitter @meteatamel for any questions or feedback.