3 common serverless patterns to build with Workflows

Partnering with Intel to accelerate cloud-native 5G
February 23, 2021
Azure webinar series: Maximize Your Windows and SQL Server Investments
February 23, 2021
Partnering with Intel to accelerate cloud-native 5G
February 23, 2021
Azure webinar series: Maximize Your Windows and SQL Server Investments
February 23, 2021

The workflow is triggered every 5 minutes and retrieves the value of the current user counter from a Firestore database using the Firestore Connector. Along with the counter value, it also retrieves the last state of the traffic, e.g., “Low”, “Normal”, “High”, that was saved during the workflow’s previous run.

Workflows’ built-in switch step, combined with a custom formula, is used to determine whether the current value of the counter would make it fall to a different state than the one saved in the previous run of the workflow. If so, the new state is saved in the Firestore database and Pub/Sub Connector pushes a message to the support team, informing them about state change. The workflow is checking not only the current value of the counter but also the last recorded state, so that only status changes result in notifications.

With only a few steps, the workflow above becomes a reliable serverless application with full tracking of execution history. Built-in Identity and Access Management (IAM) integration reduces the complexity of interacting with other Google Cloud products, like Firestore or Pub/Sub.

Learn how to schedule workflow executions using Cloud Scheduler, similar to the example above, in this guide.

Workflows with API polling

Consider a workflow that requests an execution of a long-running job using an external API. The external API accepts a job execution request and returns a unique JobID that can be used to poll for this job’s execution status. The job can take hours and the workflow can only proceed to the next steps only once this job is completed. As there is no feature in this API to notify the workflow about a job completion, the workflow needs to periodically poll for the job status.

The workflow presented below implements this pattern, checking the status of the job every 2 minutes. Note that Workflows’ pricing model is based on the number of executed steps and there is no time-related charge for a sleep operation. Workflows can run for up to a year, so you can be confident that they will follow through on even the longest-running jobs.

Leave a Reply

Your email address will not be published. Required fields are marked *