Cloud Tasks or Pub/Sub ?

Asynchronous communication in microservices

Vikram Shinde
Google Cloud - Community

--

Photo by Adrien Delforge on Unsplash

Introduction

In a world of Microservices where big application split into the loosely coupled services which can be developed, deployed and maintained independently. Microservices often don’t talk to each other via direct request/response, but rather asynchronously, allowing services to scale independently.

Asynchronous execution is a well-established way to reduce request latency and make you application more responsive. Both Cloud Tasks and Cloud Pub/Sub can be used to implement asynchronous execution.

In this blog, we’ll see which is right product for your use case.

What is Cloud Tasks?

Cloud Tasks is a fully managed service that allows you to manage the execution, dispatch and delivery of a large number of distributed tasks.

Following are the features of Cloud Task

  • Scalable and fully managed
  • HTTP targets: Add tasks targeting any HTTP service running on Cloud Run, App Engine, Cloud Functions or Compute Engine.
  • Secured: It can call secure endpoints by OAuth/OIDC authentication.
  • Rate and Retry controls: You can control the execution by setting the rate at which tasks are dispatched, maximum number of attempts and minimum amount of time to wait between attempts.
  • Future scheduling: You can control the time at which a task is run.
  • Task deduplication: Tasks can added multiple times but only dispatched once.
  • Guaranteed delivery: Tasks are guaranteed at least once.

What is Pub/Sub?

Pub/Sub is a fully-managed real-time messaging service that allows you to send and receive messages between independent applications.

Cloud Pub/Sub forwards messages from a topic to all of its subscriptions, individually. Each subscription receives messages either by Cloud Pub/Sub pushing them to the subscriber’s chosen endpoint, or by the subscriber pulling them from the service.
The subscriber receives pending messages from its subscription and acknowledges each one to the Cloud Pub/Sub service.
When a message is acknowledged by the subscriber, it is removed from the subscription’s message queue.

Following are the key features of Pub/Sub.

  • Scalable and fully managed
  • Global messaging
  • pull and push modes.
  • In-order delivery (Beta).
  • At-least-once delivery
  • Dead letter topic: Messages unable to be processed by subscriber applications to be put aside for offline debugging.
  • Filtering: Pub/Sub can filter messages based upon attributes in order to reduce delivery volume to subscribers.

Pub/Sub vs Cloud Tasks

Both Cloud Tasks and Pub/Sub can be worked as a messaging middleware for traditional service integration or simple communication medium for modern microservices.

“The core difference between Cloud Pub/Sub and Cloud Tasks is the notion of implicit vs explicit invocation”

Implicit: The publisher has no control over the delivery of the message. Pub/Sub aims to decouple publishers of events and subscribers to those events. Publishers do not need to know anything about their subscribers.

Explicit: By contrast, Cloud Tasks is aimed at explicit invocation where the publisher retains full control of execution.

Cloud Tasks has added benefits of being able to control the rate at which tasks execute, along with how often they are retried and how many concurrent tasks can be executed at the same time. Because you can control the rate at which tasks are sent from the queue, you can control the workers’ scaling behavior and hence your costs.

E.g. we have used Google Admin SDK Directory API to create and provision Google Accounts . This API has quota 1500/100 seconds.
So we controlled the calls to API using Cloud Tasks queue by setting the field max-dispatches-per-second.

Rate limits allow you to define the maximum rate and maximum number of concurrent tasks that can be dispatched by a queue

gcloud tasks queues update [QUEUE_ID] \
--max-dispatches-per-second=[MAX_DISPATCHES_PER_SECOND] \
--max-concurrent-dispatches=[MAX_CONCURRENT_DISPATCHES]

Retry parameters allow you to specify the maximum number of times to retry failed tasks, set a time limit for retry attempts, and control the interval between attempts.

gcloud tasks queues update [QUEUE_ID] \
--max-attempts=[MAX_ATTEMPTS] \
--min-backoff=[MIN_BACKOFF] \
--max-backoff=[MAX_BACKOFF] \
--max-doublings=[MAX_DOUBLINGS] \
--max-retry-duration=[MAX_RETRY_DURATION]

Another benefit of Cloud Tasks is you can pause/resume the queue using Cloud Console and CLI command to stop/start the processing of tasks.

Pull method was available in App Engine (Python2) Task Queue which is not available in Cloud Tasks. Pub/Sub has pull subscription available.

Detailed Comparison of Cloud Tasks and Pub/Sub

https://cloud.google.com/pubsub/docs/choosing-pubsub-or-cloud-tasks

Use Cases for Cloud Tasks

  • Point-2-Point Communication: Asynchronous call between 2 microservices.
  • Control Traffic: Need to control the rate so that worker’s scalability is under control. e.g. Push an asynchronous image processing job.
  • Schedule: Need to schedule the job. e.g. send an email 1 month after sign-up of trial period.
  • Stop retrying after certain number of retries.

Use Cases for Pub/Sub

  • One-to-Many: Publish message to multiple subscribers. e.g. Once order placed, publish a message to Topic which has multiple subscribers like Packaging, Shipping, Email Notification, SMS Alerts.
  • Pull subscription: Subscriber with no HTTP endpoint can pull the messages on an interval or streaming pull.

Sample Use case

The source application sends list of new employees joined in an organization. The Cloud Run validates the data and dispatches individual message into Cloud Tasks to process in parallel.

Architecture

The above use case, we need to control the API calls since there is a quota associated with the Google Admin SDK API. e.g. 1500 calls per 100 seconds.
So we introduced Cloud Tasks with max-dispatches-per-second field set to 15.

Also, once the data has been processed, we needed to update all the vendors. So we introduced Pub/Sub so the subscribers can either Pull or Push the messages.

Conclusion

We discussed about asynchronous communication between two services and how Cloud Tasks and Pub/Sub fits for it. Also looked into implicit over explicit control over a dispatch of the messages.

Pub/Sub is also mainly used for streaming process like IoT message streaming which can then be processed by Cloud Dataflow and store it in BigQuery for further analysis.

Reference

--

--