You can route a small percentage of live traffic to a new version of your Cloud Function before fully rolling it out, a technique known as a canary deployment.
Let’s see this in action. Imagine we have a Cloud Function my-function that we want to update. Currently, all traffic goes to revision v1. We’ve just deployed a new version, v2, and want to send 10% of traffic to it.
gcloud functions deploy my-function \
--region=us-central1 \
--allow-unauthenticated \
--set-cloud-sql-instances=my-project:us-central1:my-instance \
--runtime=nodejs18 \
--source=. \
--entry-point=helloWorld \
--trigger-http \
--revision=v2
Once v2 is deployed, we can split traffic using the gcloud functions command.
gcloud functions deploy my-function \
--region=us-central1 \
--allow-unauthenticated \
--set-cloud-sql-instances=my-project:us-central1:my-instance \
--runtime=nodejs18 \
--source=. \
--entry-point=helloWorld \
--trigger-http \
--revision=v2 \
--traffic 10
This command doesn’t redeploy the function. Instead, it tells Cloud Functions to start sending 10% of incoming requests to the v2 revision and the remaining 90% to the stable revision (which is v1 in this case). You can verify this by listing the function’s revisions and their traffic percentages:
gcloud functions list-revisions --region=us-central1 my-function
Output might look like:
REVISION TRAFFIC DEPLOYED
v1 90% 2023-10-27T10:00:00Z
v2 10% 2023-10-27T10:15:00Z
This gradual rollout allows you to monitor the new version for errors or performance regressions with a limited blast radius. If v2 behaves well, you can then gradually increase its traffic percentage or shift 100% of traffic to it.
gcloud functions deploy my-function \
--region=us-central1 \
--allow-unauthenticated \
--set-cloud-sql-instances=my-project:us-central1:my-instance \
--runtime=nodejs18 \
--source=. \
--entry-point=helloWorld \
--trigger-http \
--revision=v2 \
--traffic 100
After this, v1 will receive 0% of traffic, and all requests will be directed to v2.
The core mechanism that enables this traffic splitting is Cloud Functions’ integration with Google Cloud Load Balancing. When you deploy or update a function, Cloud Functions automatically provisions and configures an internal load balancer. This load balancer is responsible for distributing incoming requests across the available revisions based on the configured traffic percentages. Each revision of a Cloud Function is essentially an independent, scalable endpoint that the load balancer can target. The --traffic flag directly manipulates the backend service configuration of this internal load balancer, adjusting the weights assigned to each revision’s backend.
The surprising thing about this feature is that you can specify traffic percentages down to the exact integer. This level of granularity allows for very precise canary deployments, enabling you to test with as little as 1% of traffic if needed. However, it’s important to note that while you can specify precise percentages, the actual distribution might have some minor variance due to the underlying load balancing algorithms.
Once you’ve completed your canary deployment and are confident in the new version, you’ll typically want to clean up older, unused revisions to save on storage costs.
The next step after mastering traffic splitting is understanding how to automate this process with Cloud Build and implement robust monitoring to detect issues during a canary release.