Build a Resilient, Asynchronous System with Cloud Run and Pub/Sub

Overview

For the labs in the Serverless Cloud Run Development course, you will read through a fictitious business scenario and assist the characters with their serverless migration plan.

Twelve years ago, Lily started the Pet Theory chain of veterinary clinics. Over the years, the number of clinics has grown, and so has the need for automation. The way Pet Theory handles the results of medical tests when they come back from the lab is too slow and error-prone, and Lily wants to improve this.

Currently, Patrick, Pet Theory's IT administrator, handles test results manually. Whenever a test result comes back, he composes and sends an email to the client whose pet was tested, then he taps out a text message on his phone and sends the results as a text to the client.

Patrick is working with Ruby, a software consultant, to design a more scalable system. They want to build a solution that doesn't require a lot of ongoing maintenance. Patrick and Ruby have decided to go with serverless technology.

Objectives

In this lab, you will learn how to:

Create a Pub/Sub topic and subscription
Create a Cloud Run service that receives HTTP requests and publishes messages to Cloud Pub/Sub
Create a Cloud Run service that receives messages from Cloud Pub/Sub
Create a Pub/Sub subscription that triggers a Cloud Run service
Test the resiliency of a system

Prerequisites

This lab assumes familiarity with the Cloud Console and shell environments. This lab is part of a series. Taking the previous labs could be helpful, but is not necessary:

Setup and requirements

Note: For this lab, sign in into the Google Cloud Console as Username 1. Otherwise, you will encounter errors during the lab.

Before you click the Start Lab button

Read these instructions. Labs are timed and you cannot pause them. The timer, which starts when you click Start Lab, shows how long Google Cloud resources will be made available to you.

This hands-on lab lets you do the lab activities yourself in a real cloud environment, not in a simulation or demo environment. It does so by giving you new, temporary credentials that you use to sign in and access Google Cloud for the duration of the lab.

To complete this lab, you need:

Access to a standard internet browser (Chrome browser recommended).

Note: Use an Incognito or private browser window to run this lab. This prevents any conflicts between your personal account and the Student account, which may cause extra charges incurred to your personal account.

Time to complete the lab---remember, once you start, you cannot pause a lab.

Note: If you already have your own personal Google Cloud account or project, do not use it for this lab to avoid extra charges to your account.

Click the Start Lab button. If you need to pay for the lab, a pop-up opens for you to select your payment method. On the left is the Lab Details panel with the following:
- The Open Google Cloud console button
- Time remaining
- The temporary credentials that you must use for this lab
- Other information, if needed, to step through this lab
Click Open Google Cloud console (or right-click and select Open Link in Incognito Window if you are running the Chrome browser).

The lab spins up resources, and then opens another tab that shows the Sign in page.

Tip: Arrange the tabs in separate windows, side-by-side.

Note: If you see the Choose an account dialog, click Use Another Account.
If necessary, copy the Username below and paste it into the Sign in dialog.
```
 student-03-0a8f31fe51b7@qwiklabs.net
```
You can also find the Username in the Lab Details panel.
Click Next.
Copy the Password below and paste it into the Welcome dialog.
```
 H5GaSXqVWmCa
```
You can also find the Password in the Lab Details panel.
Click Next.

Important: You must use the credentials the lab provides you. Do not use your Google Cloud account credentials.

Note: Using your own Google Cloud account for this lab may incur extra charges.
Click through the subsequent pages:
- Accept the terms and conditions.
- Do not add recovery options or two-factor authentication (because this is a temporary account).
- Do not sign up for free trials.

After a few moments, the Google Cloud console opens in this tab.

Note: To view a menu with a list of Google Cloud products and services, click the Navigation menu at the top-left.

Navigation menu icon

Activate Cloud Shell

Cloud Shell is a virtual machine that is loaded with development tools. It offers a persistent 5GB home directory and runs on the Google Cloud. Cloud Shell provides command-line access to your Google Cloud resources.

Click Activate Cloud Shell

at the top of the Google Cloud console.

When you are connected, you are already authenticated, and the project is set to your Project_ID, qwiklabs-gcp-03-d5f5aca9030c. The output contains a line that declares the Project_ID for this session:

Your Cloud Platform project in this session is set to qwiklabs-gcp-03-d5f5aca9030c

gcloud is the command-line tool for Google Cloud. It comes pre-installed on Cloud Shell and supports tab-completion.

(Optional) You can list the active account name with this command:

gcloud auth list

Click Authorize.

Output:

ACTIVE: *
ACCOUNT: student-03-0a8f31fe51b7@qwiklabs.net

To set the active account, run:
    $ gcloud config set account `ACCOUNT`

(Optional) You can list the project ID with this command:

gcloud config list project

Output:

[core]
project = qwiklabs-gcp-03-d5f5aca9030c

Note: For full documentation of gcloud, in Google Cloud, refer to the gcloud CLI overview guide.

Set your region and zone

Certain Compute Engine resources live in regions and zones. A region is a specific geographical location where you can run your resources. Each region has one or more zones.

Run the following gcloud commands in Cloud Console to set the default region and zone for your lab:

gcloud config set compute/zone "us-east4-c"
export ZONE=$(gcloud config get compute/zone)

gcloud config set compute/region "us-east4"
export REGION=$(gcloud config get compute/region)

Scenario

Pet Theory would like to automate the process of sharing client test results. They have experienced a tough time keeping up with an increased volume of appointments, so Lily decides to ask Ruby for some assistance...

Lily, Founder of Pet Theory	Hi Ruby,
Ruby, Software Consultant	Hey Lily,

Task 1. Architecture

Pet Theory uses an external company for medical tests. Once the lab company completes a medical test, they send the results back to Pet Theory.

The lab company uses a HTTP(s) POST to Pet Theory's web endpoint for medical lab results. The illustration below outlines the general architecture.

Pet Theory's system architecture diagram

After looking at the general process followed, Ruby believes that a system can be designed in which Pet Theory is able to:

Receive the HTTP POST request and confirm receipt to the medical lab.
Email the test result to the client.
Send a text message (SMS) and an email to the client with the test result.

Ruby's design isolates each of the above activities and requires:

A service to perform the request and response for the medical result(s)
A service to email test results to the client
A service to send a text message (SMS) to the client
Pub/Sub to be used for inter-service communication
Serverless infrastructure to be used for the application architecture

Through the use of single use functions, Ruby is looking to develop code that is easier to write and contains fewer bugs.

Ruby, Software Consultant	Hi Patrick,
Patrick, IT Administrator	Hey Ruby,

Create a Pub/Sub topic

Help Patrick to create a Pub/Sub topic called new-lab-report.

Cloud Pub/Sub highlighted in architecture diagram

When a service publishes a Pub/Sub message, that message must be tagged with a topic. The Lab Report is consumed via the service to be created and publish a message for each report found.

First you need to create a topic that can be used for this task.

Run the following command to create a Pub/Sub topic:

gcloud pubsub topics create new-lab-report

Any service subscribed to the topic "new-lab-report" will be able to consume the message published by the Lab Report Service. In the above diagram you can see two such consumers, Email Service and SMS Service.

Then enable Cloud Run, which will run your code in the cloud:

gcloud services enable run.googleapis.com

Click Check my progress to verify the objective.

Create a Pub/Sub topic

Check my progress

Don't forget to update Ruby to let her know that the Pub/Sub topic is ready for her!

Patrick, IT Administrator	Hey Ruby,
Ruby, Software Consultant	Hi Patrick,

Task 2. Build the Lab Report Service

Help Ruby to set up the new Lab Report Service.

Lab Report Service highlighted in the architecture diagram

This service will serve the purpose of prototyping, so it will only do two things:

Receive the lab report HTTPS POST containing the report data.
Publish a message on Pub/Sub.

Add code for the Lab Report Service

Back in Cloud Shell, clone the repository needed for this lab:

git clone https://github.com/rosera/pet-theory.git

Move to the lab-service directory:

cd pet-theory/lab05/lab-service

Install the following packages that will be needed to receive incoming HTTPS requests and publish to Pub/Sub:

npm install express
npm install body-parser
npm install @google-cloud/pubsub

These commands update the package.json file to indicate the dependencies required for this service.

You will now edit the package.json file so that Cloud Run knows how to start your code.

Open the package.json file.
In the "scripts" section of the package.json file, add the code line "start": "node index.js", at line 7 (as shown below), and then save the file:

  "scripts": {
    "start": "node index.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

Note: Be sure to add the code exactly as provided, including the ending comma:

"start": "node index.js",

Otherwise, you will encounter errors during deployment.

Create a new file named index.js and add this code to it:

const {PubSub} = require('@google-cloud/pubsub');
const pubsub = new PubSub();
const express = require('express');
const app = express();
const bodyParser = require('body-parser');
app.use(bodyParser.json());
const port = process.env.PORT || 8080;

app.listen(port, () => {
  console.log('Listening on port', port);
});

app.post('/', async (req, res) => {
  try {
    const labReport = req.body;
    await publishPubSubMessage(labReport);
    res.status(204).send();
  }
  catch (ex) {
    console.log(ex);
    res.status(500).send(ex);
  }
})

async function publishPubSubMessage(labReport) {
  const buffer = Buffer.from(JSON.stringify(labReport));
  await pubsub.topic('new-lab-report').publish(buffer);
}

These two lines do the main work of the service:

const labReport = req.body;

await publishPubSubMessage(labReport);

Specifically, these lines:

Extract the lab report from the POST request.
Publish a PubSub message containing the newly posted lab report.

Now create a file named Dockerfile and add the code below into it:

FROM node:18
WORKDIR /usr/src/app
COPY package.json package*.json ./
RUN npm install --only=production
COPY . .
CMD [ "npm", "start" ]

This file defines how to package up the Cloud Run service into a container.

Deploy the lab-report-service

Create a file named deploy.sh and paste these commands into it:

gcloud builds submit \
  --tag gcr.io/$GOOGLE_CLOUD_PROJECT/lab-report-service
gcloud run deploy lab-report-service \
  --image gcr.io/$GOOGLE_CLOUD_PROJECT/lab-report-service \
  --platform managed \
  --region us-east4 \
  --allow-unauthenticated \
  --max-instances=1

In Cloud Shell, run the following to make this file executable:

chmod u+x deploy.sh

It's time to deploy the Lab Report Service! Run the deployment script:

./deploy.sh

Due to timing issues, you may get an error the first time you run this command. If you do, simply rerun deploy.sh.

When the deployment has successfully completed, you will see a message similar to this:

Service [lab-report-service] revision [lab-report-service-00001] has been deployed and is serving traffic at https://lab-report-service-[hash].a.run.app

Nice work, the Lab Report Service has been deployed and will consume medical lab results over HTTP. You can now test if the new service is up and running.

Click Check my progress to verify the objective.

Deploy the Lab Report Service: Build

Check my progress

Click Check my progress to verify the objective.

Deploy the Lab Report Service: Create Revision

Check my progress

Test the Lab Report Service

To validate the Lab Report Service, simulate three HTTPS POSTs made by the lab company, each containing one lab report. For the purpose of testing, the lab reports created will only contain an ID.

First, put the URL to the report in an environment variable, to make it easier to work with.

export LAB_REPORT_SERVICE_URL=$(gcloud run services describe lab-report-service --platform managed --region us-east4 --format="value(status.address.url)")

Confirm the LAB_REPORT_SERVICE_URL has been captured:

echo $LAB_REPORT_SERVICE_URL

Create a new file named post-reports.sh and add the code below into it:

curl -X POST \
  -H "Content-Type: application/json" \
  -d "{\"id\": 12}" \
  $LAB_REPORT_SERVICE_URL &
curl -X POST \
  -H "Content-Type: application/json" \
  -d "{\"id\": 34}" \
  $LAB_REPORT_SERVICE_URL &
curl -X POST \
  -H "Content-Type: application/json" \
  -d "{\"id\": 56}" \
  $LAB_REPORT_SERVICE_URL &

The above script will use the curl command to post three distinct ID's to the Lab Service URL. Each command will be run individually in the background.

Make the post-reports.sh script executable:

chmod u+x post-reports.sh

Now test the Lab Report Service endpoint by posting three lab reports to it using the script outlined above:

./post-reports.sh

This script posted three lab reports to your Lab Report Service. Check the logs to see the results!

In the Cloud console, click Navigation menu () > Cloud Run.
You should now see your newly deployed lab-report-service in the Services list. Click it.
The next page shows details about your lab-report-service. Click the Logs tab.

On the Logs page are the results of the three test reports that you just posted with the script. Hopefully the returned HTTP codes are 204, meaning OK - not content, shown below. If you don’t see any entries, try scrolling up and down using the scrollbar to the right. This reloads the log.

The next task is to write the SMS and Email services. These services will be triggered when the Lab Report Service publishes a Pub/Sub message on the "new-lab-report" topic.

Task 3. The Email Service

Help Ruby to set up the new Email Service.

Email Service highglighted in the architecture diagram

Add code for the Email Service

Move to the Email Service directory:

cd ~/pet-theory/lab05/email-service

Install these packages so that the code can handle incoming HTTPS requests:

npm install express
npm install body-parser

The above command will update the package.json file, which describes the app and its dependencies. Cloud Run needs to know how to run the code, so add start instruction so that it knows what to do.

Open the package.json file.
In the "scripts" section, add the "start": "node index.js", line as shown below and save the file:

  "scripts": {
    "start": "node index.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

Note: Be sure to add the code exactly as provided, including the ending comma:

"start": "node index.js",

Otherwise, you will encounter errors during deployment.

Create a new file called index.js and add the following to it:

const express = require('express');
const app = express();
const bodyParser = require('body-parser');
app.use(bodyParser.json());

const port = process.env.PORT || 8080;
app.listen(port, () => {
  console.log('Listening on port', port);
});

app.post('/', async (req, res) => {
  const labReport = decodeBase64Json(req.body.message.data);
  try {
    console.log(`Email Service: Report ${labReport.id} trying...`);
    sendEmail();
    console.log(`Email Service: Report ${labReport.id} success :-)`);
    res.status(204).send();
  }
  catch (ex) {
    console.log(`Email Service: Report ${labReport.id} failure: ${ex}`);
    res.status(500).send();
  }
})

function decodeBase64Json(data) {
  return JSON.parse(Buffer.from(data, 'base64').toString());
}

function sendEmail() {
  console.log('Sending email');
}

This code will run when Pub/Sub posts a message to the service. This is what it does:

It decodes the Pub/Sub message and then tries to call the sendEmail() function.
If that succeeds and no exception is thrown, it will return status code 204 so Pub/Sub knows that the message was processed.
If there is an exception, the service will return status code 500 so that Pub/Sub knows the message was not processed and it should re-post it to the service later.

Once the communication between services is working, Ruby will add code to the sendEmail() function to actually send the email.

Now create a file named Dockerfile and add the code below into it:

FROM node:18
WORKDIR /usr/src/app
COPY package.json package*.json ./
RUN npm install --only=production
COPY . .
CMD [ "npm", "start" ]

This file defines how to package up the Cloud Run service into a container.

Deploy the Email Service

Create a new file called deploy.sh and add the following to it:

gcloud builds submit \
  --tag gcr.io/$GOOGLE_CLOUD_PROJECT/email-service

gcloud run deploy email-service \
  --image gcr.io/$GOOGLE_CLOUD_PROJECT/email-service \
  --platform managed \
  --region us-east4 \
  --no-allow-unauthenticated \
  --max-instances=1

Make deploy.sh executable:

chmod u+x deploy.sh

Deploy the Email Service:

./deploy.sh

When the deployment is complete, you will see a message similar to this:

Service [email-service] revision [email-service-00001] has been deployed and is serving traffic at https://email-service-[hash].a.run.app

The service has been successfully deployed. You now need to ensure the Email Service is triggered when a Pub/Sub message is available.

Click Check my progress to verify the objective.

Deploy the Email Service: Build

Check my progress

Click Check my progress to verify the objective.

Deploy the Email Service: Create Revision

Check my progress

Configure Pub/Sub to trigger the Email Service

Whenever a new Pub/Sub message is published using the "new-lab-report" topic, it should trigger the Email Service. To achieve this task, configure a service account to automatically handle the associated requests for this service.

Architecture diagram highlights the flow from Cloud Pub/Sub to Email Service

Create a new service account that will be used to trigger the services responding to Pub/Sub messages:

gcloud iam service-accounts create pubsub-cloud-run-invoker --display-name "PubSub Cloud Run Invoker"

Click Check my progress to verify the objective.

Create a service account

Check my progress

Give the new service account permission to invoke the Email Service:

gcloud run services add-iam-policy-binding email-service --member=serviceAccount:pubsub-cloud-run-invoker@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com --role=roles/run.invoker --region us-east4 --platform managed

Next, tell Pub/Sub to invoke the SMS Service when a "new-lab-report" message is published.

Put the project number in an environment variable for easy access:

PROJECT_NUMBER=$(gcloud projects list --filter="qwiklabs-gcp" --format='value(PROJECT_NUMBER)')

Next, enable the project to create Pub/Sub authentication tokens.

Run the code below:

gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT --member=serviceAccount:service-$PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com --role=roles/iam.serviceAccountTokenCreator

Put the URL of the Email Service in another environment variable:

EMAIL_SERVICE_URL=$(gcloud run services describe email-service --platform managed --region us-east4 --format="value(status.address.url)")

Confirm the EMAIL_SERVICE_URL has been captured:

echo $EMAIL_SERVICE_URL

Create a Pub/Sub subscription for the Email Service.

gcloud pubsub subscriptions create email-service-sub --topic new-lab-report --push-endpoint=$EMAIL_SERVICE_URL --push-auth-service-account=pubsub-cloud-run-invoker@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com

Nice work! The service is now set up to respond to Cloud Pub/Sub messages. As a next step, validate the code to confirm it meets requirements.

Click Check my progress to verify the objective.

Create the Pub/Sub subscription

Check my progress

Test the Lab Report Service and the Email Service together

Using the script created earlier, post to the lab reports again:

~/pet-theory/lab05/lab-service/post-reports.sh

Then open the log (Navigation menu > Cloud Run). You will see the two Cloud Run services, email-service and lab-report-service, in your account.
Click email-service and then click Logs.
You will see the result of this service being triggered by Pub/Sub. If you don’t see the messages you expect, you may need to scroll up and down with the scrollbar to get the log to refresh.

Great job! The Email service is now able to write information to the log whenever a message is processed from the Cloud Pub/Sub topic queue! The last task is to write the SMS Service.

Task 4. The SMS Service

Help Ruby to set up the new SMS Service.

SMS Service highlighted in the architecture diagram

Add code for the SMS Service

Create a directory for the SMS Service:

cd ~/pet-theory/lab05/sms-service

Install the packages required to receive incoming HTTPS requests:

npm install express
npm install body-parser

Open the package.json file.
In the "scripts" section, add the "start": "node index.js", line as shown below and save the file:

...

"scripts": {
    "start": "node index.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

...

Note: Be sure to add the code exactly as provided, including the ending comma:

"start": "node index.js",

Otherwise, you will encounter errors during deployment.

Create a new file called index.js and add the following to it:

const express = require('express');
const app = express();
const bodyParser = require('body-parser');
app.use(bodyParser.json());

const port = process.env.PORT || 8080;
app.listen(port, () => {
  console.log('Listening on port', port);
});

app.post('/', async (req, res) => {
  const labReport = decodeBase64Json(req.body.message.data);
  try {
    console.log(`SMS Service: Report ${labReport.id} trying...`);
    sendSms();

    console.log(`SMS Service: Report ${labReport.id} success :-)`);    
    res.status(204).send();
  }
  catch (ex) {
    console.log(`SMS Service: Report ${labReport.id} failure: ${ex}`);
    res.status(500).send();
  }
})

function decodeBase64Json(data) {
  return JSON.parse(Buffer.from(data, 'base64').toString());
}

function sendSms() {
  console.log('Sending SMS');
}

Now create a file named Dockerfile and add the code below into it:

FROM node:18
WORKDIR /usr/src/app
COPY package.json package*.json ./
RUN npm install --only=production
COPY . .
CMD [ "npm", "start" ]

This file defines how to package up the Cloud Run service into a container. Now the code has been created, the next step is to deploy the service.

Deploy the SMS Service

Create a file named deploy.sh and add this code into it:

gcloud builds submit \
  --tag gcr.io/$GOOGLE_CLOUD_PROJECT/sms-service

gcloud run deploy sms-service \
  --image gcr.io/$GOOGLE_CLOUD_PROJECT/sms-service \
  --platform managed \
  --region us-east4 \
  --no-allow-unauthenticated \
  --max-instances=1

Make deploy.sh executable:

chmod u+x deploy.sh

Deploy the SMS Service:

./deploy.sh

When the deployment is complete, a message similar to this is displayed:

Service [sms-service] revision [sms-service-00001] has been deployed and is serving traffic at https://sms-service-[hash].a.run.app

The SMS Service is successfully deployed, but it isn't linked to the Cloud Pub/Sub service. Correct that in the next section.

Click Check my progress to verify the objective.

Deploy the SMS Service

Check my progress

Configure Cloud Pub/Sub to trigger the SMS Service

As with the Email Service, the link between Cloud Pub/Sub and the SMS service needs to be configured so that messages can be consumed.

The architecture diagram highlights the flow from Cloud Pub/Sub to SMS Service

Set the permissions to allow Pub/Sub to trigger the SMS Service:

gcloud run services add-iam-policy-binding sms-service --member=serviceAccount:pubsub-cloud-run-invoker@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com --role=roles/run.invoker --region us-east4 --platform managed

Next, tell Pub/Sub to invoke the SMS Service when a “new-lab-report” message is published.

The first step is to put the URL address of the SMS Service in an environment variable:

SMS_SERVICE_URL=$(gcloud run services describe sms-service --platform managed --region us-east4 --format="value(status.address.url)")

Confirm the SMS_SERVICE_URL has been captured:
```
 echo $SMS_SERVICE_URL
```
Then create the Pub/Sub subscription:

gcloud pubsub subscriptions create sms-service-sub --topic new-lab-report --push-endpoint=$SMS_SERVICE_URL --push-auth-service-account=pubsub-cloud-run-invoker@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com

Run the test script again to post three lab reports to the Lab Report Service:

~/pet-theory/lab05/lab-service/post-reports.sh

Then open the log (Navigation menu > Cloud Run). You will see the three Cloud Run services, email-service, lab-report-service, and sms-service, in your account.
Click sms-service, then click Logs. You will see the result of this service being triggered by Pub/Sub.

The prototype system has been created and successfully tested. However, Patrick is concerned that resilience, as part of the initial validation process, hasn't been tested.

Task 5. Test the resiliency of the system

What happens if one of the services goes down? Patrick has run into this before, as it is a common situation.

Help Ruby investigate how to ensure the system can handle this scenario. She wants to test what happens when a service fails by deploying a bad version of the Email Service.

Go back to the email-service directory:

cd ~/pet-theory/lab05/email-service

Add some invalid text to the Email Service application to cause an error.

Edit index.js and add the throw line to the sendEmail() function, as shown below. This will throw an exception, as if the email server was down:

...

function sendEmail() {
  throw 'Email server is down';
  console.log('Sending email');
}
...

The addition of this code will crash the service when it is invoked.

Deploy this bad version of the Email Service:

./deploy.sh

When the Email Service deployment has successfully completed, post data to the lab reports again, then go and watch the email-service log status closely:

~/pet-theory/lab05/lab-service/post-reports.sh

Open the Email Service logs to view the logs for the bad Email Service: Navigation menu > Cloud Run.
When you see the three Cloud Run services in your account, click email-service.

The Email Service is being invoked, but it will keep crashing. If you scroll back a bit in the logs you will find the root cause: “Email server is down”. You can also see that the service returns status code 500, and that Pub/Sub keeps retrying calling the service.

If you look at the logs from the SMS service, you will see that it operates successfully.

Now fix the error in the Email Service to restore the application!

Open the index.js file and remove the throw line you previously entered, then save the file.

Your index.js sendEmail function show now look similar to this:

function sendEmail() {
  console.log('Sending email');
}

Deploy the fixed version of the Email Service:

./deploy.sh

When the deployment has finished, click the refresh icon in the top right corner.

You will see how the emails for report 12, 34 and 56 were finally sent, the Email Service returned the status code 204, and Pub/Sub stopped invoking the service. No data was lost; Pub/Sub kept retrying until it was finally successful. This is the foundation of a robust system!

Takeaways

If services communicate asynchronously with each other via Pub/Sub instead of calling each other directly, the system can be more resilient.
The Lab Report Service trigger is independent of other services, thanks to the use of Pub/Sub. For example, if customers should also want to receive lab results via another messaging service, it can be added without needing to update the Lab Report Service.
Cloud Pub/Sub handled the retries, the services didn't have to. Services are only required to return a status code: success or failure.
If a service goes down, the system is capable of automatically "healing" itself when the service comes back online, thanks to Pub/Sub retries.

Solution of Lab

New Solution

https://youtu.be/r24fl8MLNs8

curl -LO raw.githubusercontent.com/ePlus-DEV/storage/refs/heads/main/labs/GSP250/lab.sh
source lab.sh

Script Alternative

curl -LO https://raw.githubusercontent.com/Itsabhishek7py/GoogleCloudSkillsboost/refs/heads/main/Build%20a%20Resilient%2C%20Asynchronous%20System%20with%20Cloud%20Run%20and%20PubSub/abhishek.sh
sudo chmod +x abhishek.sh
./abhishek.sh

Old Solution

https://youtu.be/-t8-RUhEWCg

curl -LO raw.githubusercontent.com/Techcps/Google-Cloud-Skills-Boost/master/Build%20a%20Resilient,%20Asynchronous%20System%20with%20Cloud%20Run%20and%20PubSub/techcps650.sh
sudo chmod +x techcps650.sh
./techcps650.sh

Build a Resilient, Asynchronous System with Cloud Run and Pub/Sub - GSP650

Comments

Tip & Tricks

More from this blog

Daily Tech Brief — 01/08/2026

Daily Tech Brief — 31/07/2026

Daily Tech Brief — 30/07/2026

Get Started with Vibe Coding and Gemini CLI - GSP1348

Build an AI Image Recognition app using Gemini on Agent Platform - bb-ide-genai-001

Overview

Objectives

Prerequisites

Setup and requirements

Before you click the Start Lab button

Activate Cloud Shell

Set your region and zone

Scenario

Task 1. Architecture

Create a Pub/Sub topic

Task 2. Build the Lab Report Service

Add code for the Lab Report Service

Deploy the lab-report-service

Test the Lab Report Service

Task 3. The Email Service

Add code for the Email Service

Deploy the Email Service

Configure Pub/Sub to trigger the Email Service

Test the Lab Report Service and the Email Service together

Task 4. The SMS Service

Add code for the SMS Service

Deploy the SMS Service

Configure Cloud Pub/Sub to trigger the SMS Service

Task 5. Test the resiliency of the system

Takeaways

Solution of Lab

New Solution

Old Solution

Command Palette

Comments

Tip & Tricks

More from this blog

Overview

Objectives

Prerequisites

Setup and requirements

Before you click the Start Lab button

How to start your lab and sign in to the Google Cloud console

Activate Cloud Shell

Set your region and zone

Scenario

Task 1. Architecture

Create a Pub/Sub topic

Task 2. Build the Lab Report Service

Add code for the Lab Report Service

Deploy the lab-report-service

Test the Lab Report Service

Task 3. The Email Service

Add code for the Email Service

Deploy the Email Service

Configure Pub/Sub to trigger the Email Service

Test the Lab Report Service and the Email Service together

Task 4. The SMS Service

Add code for the SMS Service

Deploy the SMS Service

Configure Cloud Pub/Sub to trigger the SMS Service

Task 5. Test the resiliency of the system

Takeaways

Solution of Lab

New Solution

Old Solution