Cloud

We launched session affinity for Cloud Run services this June (in preview). You can use session affinity to improve responsiveness of services that store client-specific state on container instances.  In this blog, I’ll dive deeper into when session affinity is useful for you and I’ll show you how it works on Cloud Run.

With session affinity enabled, requests from the same client are routed to the same container instance (if it is available). Examples of services that are likely to benefit from session affinity include those that make heavy use of local caching on container instances and services that use long-running connections such as WebSockets. 

If you’re already excited and want to try out session affinity right now, refer to setting session affinity in the Cloud Run documentation. 

When trying to understand session affinity, you shouldn’t think of server-side sessions. Session affinity does not enable you to durably persist server-side session data directly on the container instance. If you do this, your customers will complain about occasionally having to log in again, or about losing the contents of their shopping cart. I’ll tell you more below in “Store server-side session data in a persistent store”. 

What is Cloud Run? 

First, a short introduction for those of you who aren’t familiar with Cloud Run. (If you are familiar, skip down to  “Session affinity by example”.)

Cloud Run is a fully-managed compute platform that lets you run your code in a container directly on top of Google’s scalable infrastructure. We’ve intentionally designed Cloud Run to make developers more productive – you get to focus on writing your code and Cloud Run takes care of running it.

There are two ways to run your code on Cloud Run. Services are used to run code that responds to web requests or events, and jobs are used to run code that runs to completion. Session affinity only applies to services since it’s a request routing feature. 

Session affinity by example

Cloud Run makes sure to handle all requests that come in by starting additional containers to distribute the load. Without session affinity (the default), requests from one client can be handled by any container instance, as shown here: 

If you enable session affinity, requests from the same client will be routed to the same container instance, provided that is available and has capacity to handle the request.

How does session affinity work? 

Let’s dive into how session affinity works so you can learn how to make the most of it. When Cloud Run responds to the first request from a client, it adds a generated session affinity cookie as a response header. Cloud Run can identify the container that served the request from this cookie:

For every subsequent request from the same client, Cloud Run routes the request to the container instance that the session affinity cookie links to.  

Handling cookies on the client

Browsers handle cookies transparently for you. If a server sends a response header with a cookie, your browser adds the cookie to subsequent requests. 

If you’re sending requests programmatically you often need to explicitly manage cookies. If you’re sending requests from your code, you need to make sure that the session affinity cookie is added to all requests. This also applies if you’re sending requests from a script using a tool such as curl.

WebSocket streams use session affinity cookies in the same way as requests do. If a browser starts a WebSocket, it initializes the stream with a HTTP-based handshake that includes cookies. If that doesn’t make sense right now, don’t worry, I’ll dive deeper into it further down in “WebSockets reconnect to the same instance with session affinity”

Session affinity is all about avoiding the cost of rebuilding local state

Now that you know how session affinity works on Cloud Run, let’s make its benefits more concrete using an example of an application that makes heavy use of local caching on container instances. The example is based on an application I once built.

Let’s imagine you’re building a dashboard that lets users visualize query results. Users can view results and drill down using filters. Your application requests the data from an ancient backend system that isn’t very performant. You can’t send too many queries at the same time, and the response times are in the order of 10s of seconds. 

Since you want to provide your users with a great experience, you’ve introduced caching to increase the responsiveness of the dashboard. Every time your application makes a query to the slow backend, it makes sure to store the results in memory. When users apply filters to the data, your code doesn’t send additional queries to the slow backend, but it filters the in-memory result set instead. 

The results in the dashboard are client-specific, since every client tends to view different data. In essence, your application stores a big lookup table in memory with the client ID as the key and the cached results as the value. Thankfully, you found a library that handles all the hard parts of caching. All you have to do is get the results, and the library takes care of invalidating outdated records and maintaining a maximum size in memory.

Caching works so well for this dashboard, you’re even thinking about predicting future queries to prefetch results. 

As your service grows more popular, you discover an issue. Performance gets progressively worse when there’s heavy traffic to your service. It looks like your in-memory cache is not used effectively when Cloud Run starts adding additional containers to handle all requests. 

As Cloud Run adds container instances to handle incoming traffic, clients are likely to send subsequent requests to an instance that doesn’t have their cached results, and your application ends up unnecessarily re-requesting the data from the backend system again. 

Session affinity helps to resolve this problem, since it makes a best effort to route client requests to the same container instance every time, allowing effective use of the query results cache. 

I’m sure you can think of similar examples. Session affinity is all about avoiding the cost of rebuilding local state.

What happens when the container can’t handle a request?

If Cloud Run receives a request for a container instance that can’t handle the request, Cloud Run still serves the request and uses a different container instance. 

Cloud Run sends a response with an updated session affinity cookie that points to the new container instance. All subsequent requests will be served by the new container instance.

When does Cloud Run select a different container to serve the request? 

There are various reasons why a container can be unavailable to handle requests. One reason can be that the container instance has been removed from the service. The Cloud Run autoscaler removes container instances as it scales in, and session affinity doesn’t keep container instances alive.

The other reasons have to do with the capacity of the container to handle requests. Cloud Run wants to make sure that the container can serve the request if it forwards it. Here are two examples of reasons why Cloud Run might decide to break session affinity and serve a request using a different container instance:

Concurrency limit

Handling the request would cause the container to exceed the maximum concurrency of the container instance. Cloud Run limits the number of requests that can be handled by a container at the same time (refer to concurrency to learn more about this configurable setting). 

High CPU

Cloud Run avoids sending requests to container instances with high CPU utilization.

What happens when Cloud Run scales out the number of container instances? 

Cloud Run automatically adds container instances to handle all incoming requests (that’s called scaling out). When a scale out event happens, the affinity of existing clients doesn’t change immediately. If Cloud Run receives a request with a session affinity cookie, it always tries to honor the affinity and deliver the request to the designated container instance.

One thing to keep in mind is that scale outs happen when the existing container instances are already busy handling requests and Cloud Run thinks it’s time to add more. The affinity of existing clients might change when their requests hit overloaded instances and are moved off to newly started instances. 

Container lifetime is not guaranteed for the duration of a session

While the session affinity cookie has a set lifetime of 30 days, that doesn’t mean Cloud Run keeps a container instance ready for your client for 30 days. Regardless whether clients have affinity with a container instance, Cloud Run can decide to restart or remove the container instance. 

Don’t worry, container instances remain active while serving requests. To stop a container, Cloud Run first stops forwarding requests to an instance, warns the container using theSIGTERM signal, before finally stopping it after a grace period of 10 seconds. 

Store server-side session data in a persistent store

Server side session data is data that relates to a user session. Examples include the contents of a shopping cart, or the logged-in status of a user. You should always store this data in a persistent store. 

Many web frameworks store server-side session data on the filesystem by default. That’s great for a local development environment, but on Cloud Run it doesn’t work so well, even with session affinity enabled. 

To understand why, recall how on Cloud Run session affinity is a best effort. As I outlined earlier in this article, there are several reasons why a request can land on a different container instance than the container instance that served the first request. If your application stored the shopping cart content on the first container instance, that session data is lost to the client when the affinity moves to another container instance. The user sees an empty cart.

On Google Cloud, there are several options available to store server-side session data. One option is to use Memorystore, which is a fully-managed Redis or Memcached. A proprietary alternative is Firestore, our managed NoSQL document store. If you choose one of the multi-regional locations of Firestore, you get a 99.999% monthly uptime service level agreement (SLA).

WebSockets reconnect to the same instance with session affinity

Before I’m wrapping up this article, I’d like to dive deeper into another use case I called out in the introduction – applications that use WebSockets.

WebSockets are popular because they provide web servers with a way to send messages directly to connected clients. WebSockets are an end-to-end connection between a client (usually a browser) and a server, enabling use cases that include message notifications, collaborative editing tools, and multiplayer games. Cloud Run has complete support for WebSockets by default – no configuration needed. 

As long as the connection is open, Cloud Run won’t stop the container instance – we’ve documented that right here in the container runtime contract. You might wonder why you should care about session affinity when using WebSockets.

The reality is that connections can break for various reasons, including application errors. You should also keep in mind that Cloud Run enforces the maximum duration of requests for WebSockets too. If a connection lasts for longer than the timeout, Cloud Run terminates the connection.

If a WebSocket connection is disrupted, it’s convenient if the client reconnects to the same instance, to avoid having to rebuild any server-side state. If you’re building a game, you’d like to avoid additional lag, or you don’t like to restore a player to the last state that was snapshotted and persisted. 

With session affinity, both requests and WebSockets are routed to the instance that served the first request, if it’s still there and has capacity.  

WebSockets start as a regular HTTP/1.1 request and response

Session affinity works in the same way with requests and WebSockets, because if your browser initializes a new WebSocket connection, it starts with an HTTP-based handshake, as shown here: 

To create a WebSocket, the following happens: 

The client opens a new TCP connection.

The client sends a regular HTTP/1.1 request that includes an Upgrade header, inviting the server to change protocols from HTTP to the WebSocket protocol. 

The server responds with an HTTP response that has status code 101 – Switching Protocols.

Both the server and client switch to the WebSocket protocol immediately.

The HTTP request and response handshake that initiates a WebSocket connection can include HTTP headers, including the session affinity cookie.

Don’t worry, you’ll never find yourself implementing a WebSocket server on the protocol level. Libraries that help you create a WebSocket server are available for all major programming languages. Socket.io is a very popular example in Node.js.

Summary

In this post, you learned about the new feature session affinity we’re previewing since this June. This is what’s important to remember about session affinity:

It routes client requests to the same instance that served the initial request, using a generated session affinity cookie. 

It’s all about avoiding the cost of rebuilding local state, use it as an optimization.

It’s a best effort, not a guarantee. A container might be unavailable or out of capacity when a request comes in, in which case Cloud Run moves the affinity to a different container.

Definitely don’t use it for storing data that needs to persist between requests and can’t be easily rebuilt, such as server-side session data.

Next steps

Here are some ideas for where to go next: 

Work through the codelab Dev to Prod in Three Easy Steps with Cloud Run that shows you how to build a small web app and deploy it to Cloud Run. 

Learn how to enable session affinity.

Session affinity launched in preview and we’re looking forward to hearing your feedback. Reach out to me if you have any feedback! I’m @wietsevenema on Twitter and Wietse Venema on LinkedIn. 

In security, the three “A”s of controlling access are Authentication (Who is the user?), Authorization (What is the user allowed to do?), and Auditing (What are they doing?) Going a bit deeper:

Authentication (AuthN): Authentication is the process of identifying a user through a private form of verification (for example, a password, a certificate, a key, and so on). In Google Cloud, Cloud Identity performs authentication.

Authorization (AuthZ): Authentication on its own provides no set of permissions; authorization is used to set permissions that a user is allocated post authentication. In Google Cloud, Cloud IAM is used for authorization (and Cloud Identity for assigning admin roles with broad default permissions).

Auditing: Auditing is about monitoring the resources accessed or modified by a particular identity.  In Google Cloud, Cloud Audit Logging helps with auditing resources and the Reports API helps auditing in Cloud Identity operations. You can also integrate the logs with prominent SIEM systems.

This post is focused on authentication.

What is Cloud Identity?

Cloud Identity is the identity provider (IdP) for Google Cloud. It also is the Identity-as-a-Service (IDaaS) solution that powers Google Workspace. It stores and manages digital identities for Google Cloud users. When you migrate to or start using Cloud Identity, you create an account at no charge for each of your users from the Google Admin console. Cloud Identity (free version) comes with a limit of 50 users, customers can either purchase cloud identity premium (paid subscription) or request CI free license increase (done based on justification). Cloud Identity provides user lifecycle management, account security, and single sign-on (SSO) support. 

Setting up Cloud Identity is a prerequisite to onboarding your organization onto Google Cloud. Here is how it works: 

Upon setting up your Cloud Identity instance you will be asked to add a domain that you own (typically your company’s main domain)

You will be asked to validate that you own this domain; this is most typically done through adding TXT record in your DNS records.

Once this validation is complete, a Google Cloud organization will be created with the same name as your domain and you can begin using Google Cloud.

How Cloud Identity connects with Google Cloud

There are a variety of ways in which identities can be imported into Cloud Identity: manually, through a CSV file or using APIs and third party IdP systems. Once set up, users and groups will be used by Cloud IAM to grant access to Google Cloud resources. It’s important to understand that Cloud Identity roles are used for user/group management and are distinct from Google Cloud IAM roles, which manage permissions to cloud resources. This distinction will be covered in more detail in a separate post on Cloud IAM authorization.

Authentication options

Aside from username and password, there are two frequently used authentication options:

2-Step Verification (2SV) with Google authentication

2-Step Verification adds a second factor for authentication in addition to a username and password. However,  not all the 2SV methods are the same. SMS, backup codes, one-time passwords (OTP), and mobile push prompts provide additional protection but they are still phishable. FIDO Universal 2nd Factor (U2F) security keys are highly phishing-resistant. The U2F protocol uses cryptography to verify a user’s identity and URLs of the website that is being accessed. Keys stay on the device so there are no server-side shared secrets to steal, which helps protect against phishing, man-in-the-middle, and replay attacks.

Google recommends security keys for security. Further, security keys should be considered mandatory for admins for optimal security. Google offers the Titan Security Key, which includes special firmware engineered by Google to verify the key’s integrity. Android and iOS devices can also be used as security keys (requires Bluetooth). With the Titan Security Key, the user experience is similar to signing on via the Google prompt but the protection is stronger, because the key uses the FIDO U2F protocol.

Cloud Identity also offers the possibility to require 2SV with a third-party IdP (e.g., Azure AD or Okta). For example, with this option a user will login in Azure AD by entering her password, and after a successful SAML exchange between the IdP (Azure AD) and Google will be challenged with the 2SV method set up in Google as an extra authentication step. Post SAML SSO verification is not static (e.g will not be challenged every time), rather risk based.

SSO authentication with a third-party identity provider

You can also delegate authentication using SSO to a third-party SAML 2.0 identity provider, such as Okta, Ping, Active Directory Federation Services (AD FS), or Azure AD. This method normally means faster Google Cloud onboarding and less disruption if you are already using a compatible IdP.  

That was a bird’s eye view of authentication options in Google Cloud. Once your users are authenticated they need to be authorized to perform any actions they may want to take. Authorization with Cloud IAM is covered here. For a more in-depth look at Cloud Identity check out the documentation.  

For more #GCPSketchnote, follow the GitHub repo. For similar cloud content follow me on Twitter @pvergadia and keep an eye out on thecloudgirl.dev 

Today we are excited to announce the release of over twenty new BigQuery and BigQuery ML (BQML) operators for Vertex AI Pipelines, that help make it easier to operationalize BigQuery and BQML jobs in a Vertex AI Pipeline. The first five BigQuery and BQML pipeline components were released earlier this year. These twenty-one new, first-party, Google Cloud-supported components help data scientists, data engineers, and other users incorporate all of Google Cloud’s BQML capabilities including forecasting, explainable AI, and MLOps. 

The seamless integration between BQML and Vertex AI helps automate and monitor the entire model life cycle of BQML models from training to serving. Developers, especially ML engineers, no longer have to write bespoke code in order to include BQML workflows in their ML pipelines, they can now simply include these new BQML components in their pipelines natively, making it easier and faster to deploy end-to-end ML lifecycle pipelines.  

In addition, using these components as part of a Vertex AI Pipelines provides data and model governance. Any time a pipeline is executed, Vertex AI Pipelines tracks and manages any artifacts produced automatically.  

For BigQuery, the following components are available:

BigQuery 

Category

Component

Description

Query

BigqueryQueryJobOp

Allows users to submit an arbitrary BQ query which will either be written to a temporary or permanent table. Launches a BigQuery query job and waits for it to finish.

For BigQuery ML (BQML), the following components are now available:

BigQuery ML

Category

Component

Description

Core

BigqueryCreateModelJobOp

Allow users to submit a DDL statement to create a BigQuery ML model.

BigqueryEvaluateModelJobOp

Allows users to evaluate a BigQuery ML model.

BigqueryPredictModelJobOp

Allows users to make predictions using a BigQuery ML model.

BigqueryExportModelJobOp

Allows users to export a BigQuery ML model to a Google Cloud Storage bucket 

New Components

Forecasting

BigqueryForecastModelJobOp

Launches a BigQuery ML.FORECAST job and lets you forecast an ARIMA_PLUS or ARIMA model. 

BigqueryExplainForecastModelJobOp

Launches a BigQuery ML.EXPLAIN_FORECAST job and let you forecast an ARIMA_PLUS or ARIMA model

BigqueryMLArimaEvaluateJobOp

Launches a BigQuery ML.ARIMA_EVALUATE job and waits for it to finish.

Anomaly
Detection

BigqueryDetectAnomaliesModelJobOp

Launches a BigQuery detect anomaly model job and waits for it to finish.

Model Evaluation

BigqueryMLConfusionMatrixJobOp

Launches a BigQuery confusion matrix job and waits for it to finish.

BigqueryMLCentroidsJobOp

Launches a BigQuery ML.CENTROIDS job and waits for it to finish

BigqueryMLTrainingInfoJobOp

Launches a BigQuery ml training info fetching job and waits for it to finish.

BigqueryMLTrialInfoJobOp

Launches a BigQuery ml trial info job and waits for it to finish.

BigqueryMLRocCurveJobOp

Launches a BigQuery roc curve job and waits for it to finish.

Explainable AI

BigqueryMLGlobalExplainJobOp

Launches a BigQuery global explain fetching job and waits for it to finish.

BigqueryMLFeatureInfoJobOp

Launches a BigQuery feature info job and waits for it to finish.

BigqueryMLFeatureImportanceJobOp

Launches a BigQuery feature importance fetch job and waits for it to finish.

Model Weights

BigqueryMLWeightsJobOp

Launches a BigQuery ml weights job and waits for it to finish.

BigqueryMLAdvancedWeightsJobOp

Launches a BigQuery ml advanced weights job and waits for it to finish.

BigqueryMLPrincipalComponentsJobOp

Launches a BigQuery ML.PRINCIPAL_COMPONENTS job and waits for it to finish.

BigqueryMLPrincipalComponentInfoJobOp

Launches a BigQuery ML.principal_component_info job and waits for it to finish.

BigqueryMLArimaCoefficientsJobOp

Launches a BigQuery ML.ARIMA_COEFFICIENTS job and lets you see the ARIMA coefficients. 

Model Inference

BigqueryMLReconstructionLossJobOp

Launches a BigQuery ML reconstruction loss job and waits for it to finish.

BigqueryExplainPredictModelJobOp

Launches a BigQuery explain predict model job and waits for it to finish

BigqueryMLRecommendJobOp

Launches a BigQuery ML.Recommend job and waits for it to finish.

Other

BigqueryDropModelJobOp

Launches a BigQuery drop model job and waits for it to finish.

Now that you have a broad overview of all pipeline operators for BQML available, let’s see how to use forecasting ones in the end-to-end example of building demand forecast predictions. You will find the code in the Vertex AI samples repo on Github. 

Example of a demand forecast predictions pipeline in BigQuery ML

In this section, we’ll show an end-to-end example of using BigQuery and BQML components in a Vertex AI Pipeline for demand forecasting. The pipeline is based on the solving for food waste with data analytics blog post. In this scenario, a fictitious grocer, FastFresh, specialized in selling fresh food distribution, wants to minimize food waste and optimize stock levels across all stores. Due to the frequency of inventory updates (by minute of every single item), they want to train a demand forecasting model on an hourly basis. With 24 training jobs per day, they want to automate model training using an ML pipeline using pipeline operators for BQML ARIMA_PLUS, the forecasting model type in BQML. 

Below you can see a high level picture of the pipeline flow

From top to bottom: 

Create the training dataset in BigQuery 

Train a BigQuery ML ARIMA_PLUS model

Evaluate ARIMA_PLUS time series and model metrics

Then, if the average mean absolute error (MAE), which measures the mean of the absolute value of the difference between the forecasted value and the actual value, is less than a certain threshold:

Generate time series forecasts based on a trained time series ARIMA_PLUS model

Generate separate time series components of both the training and the forecasting data to explain predictions

Let’s dive into the pipeline operators for BQML ARIMA_PLUS.

Training a demand forecasting model

Once you have the training data (as a table), you are ready to build a demand forecasting model with the ARIMA_PLUS algorithm. You can automate this BQML model creation operation within a Vertex AI Pipeline using the BigqueryCreateModelJobOp. As we discussed in the previous article, this component allows you to pass the BQML training query to submit a model training of an ARIMA_PLUS model on BigQuery. The component returns a google.BQMLModel which will be recorded in the Vertex ML Metadata so that you can keep track of the lineage of all artifacts. Below you find the model training operator where the set_display_name attribute allows you to name the component during the execution. And the after attribute allows you to control the sequential order of the pipeline step. 

Evaluating time series and model metrics

Once you train the ARIMA_PLUS model, you would need to evaluate the model before generating predictions. In BigQuery ML, you have ML.ARIMA_EVALUATE and ML.EVALUATE functions. The ML.ARIMA_EVALUATE function generates both statistical metrics such as log_likelihood, AIC, and variance and other time series information about seasonality, holiday effects, spikes-and-dips outliers, etc. for all the ARIMA models trained with the automatic hyperparameter tuning enabled by default (auto.ARIMA). The ML.EVALUATE retrieves forecasting accuracy metrics such as the mean absolute error (MAE) and the mean squared error (MSE). To integrate those evaluation functions in a Vertex AI pipeline you can now use the corresponding BigqueryMLArimaEvaluateJobOp and BigqueryEvaluateModelJobOp operators. In both cases they take google.BQMLModel as input and return Evaluation Metrics Artifact as output. 

For the BigqueryMLArimaEvaluateJobOp, here is an example of it used in a pipeline component:

Below is the view of statistical metrics (the first five columns) resulting from BigqueryMLArimaEvaluateJobOp operators in a BigQuery table.

For the BigqueryEvaluateModelJobOp, below you have the corresponding pipeline component:

Where you have a query statement to select the test sample to generate evaluation forecast metrics.

As Evaluation Metrics Artifacts in the Vertex ML metadata, you can consume those metrics afterwards for visualizations in the Vertex AI Pipelines UI using Kubeflow SDK visualization APIs. Indeed, Vertex AI allows you to render that HTML in an output page which is easily accessible from the Google Cloud console. Below is an example of a custom forecasting HTML report you can create.

Also you can use those values to implement conditional if-else logic using Kubeflow SDK condition in the pipeline graph. In this scenario, a model performance condition has been implemented using the average mean squared error in a way that if the trained model average mean squared error is below a certain threshold then the model can be consumed to generate forecast predictions. 

Generate and explain demand forecasts

To generate forecasts in the next n hours, you can use the BigqueryForecastModelJobOp which launches a BigQuery forecast model job. The component consumes the google.BQMLModel as Input Artifact and allows you to set the number of time points to forecast (horizon) and the percentage of the future values that fall in the prediction interval (confidence_level). In the example below it has been decided to generate hourly forecasts with a confidence interval of 90%. 

Then forecasts are materialized in a predefined destination table using the job_configuration_query parameter which will be tracked as google.BQTable in the Vertex ML Metadata. Below is an example of the forecast table you would get (only the five columns). 

After you generate your forecasts, you can also explain them using the BigqueryExplainForecastModelJobOp which extends the capabilities of BigqueryForecastModelJobOp operator and allows to use the ML.EXPLAIN_FORECAST function which provides extra model explainability like trend, detected seasonality, and holiday effects.

At the end, here you will see the visualization of the overall pipeline you define in the Vertex AI Pipelines UI.

And if you want to analyze, debug, and audit ML pipeline artifacts and their lineage, you can access the following representation in the Vertex ML Metadata by clicking on one of the yellow artifact objects rendered by the Google Cloud console.

Conclusion

In this blogpost, we described the new BigQuery and BigQuery ML (BQML) components now available for Vertex AI Pipelines, enabling data scientists and ML engineers to orchestrate and automate any BigQuery and BigQuery ML functions. We also showed an end-to-end example of using the components for demand forecasting involving BigQuery ML and Vertex AI Pipelines. 

What’s next

Are you ready for running your BQML pipeline with Vertex AI Pipelines? Check out the following resources and give it a try: 

Documentation

BigQuery ML

Vertex AI Pipelines

BigQuery and BigQuery components for Vertex AI Pipelines

Code Labs

Intro to Vertex Pipelines

Using Vertex ML Metadata with Pipelines

Vertex AI Samples: Github repository

Video Series: AI Simplified: Vertex AI

Quick Lab: Build and Deploy Machine Learning Solutions on Vertex AI

References 

https://cloud.google.com/blog/products/data-analytics/solving-for-food-waste-with-data-analytics-in-google-cloud

https://cloud.google.com/architecture/build-visualize-demand-forecast-prediction-datastream-dataflow-bigqueryml-looker

https://cloud.google.com/blog/topics/developers-practitioners/announcing-bigquery-and-bigquery-ml-operators-vertex-ai-pipelines 

A few weeks ago, we announced the new homepage for Google Cloud, redesigned for simplicity, performance, and navigation. Today, we’d like to share a deeper insight into Quick Access, a new feature of Active Assist that powers this new streamlined homepage experience.

Quick Access introduces intelligent shortcuts that reduce the average time it takes you to navigate from the homepage to your desired destination/task by up to 43%. It helps eliminate the need to search or browse for the specific page within Google Cloud you’re looking to get to. Quick Access uses machine learning to predict the destinations you will most likely want to navigate to based on an understanding of your Google Cloud console activity, and common cloud workflows. It is personalized for Google Cloud users who have personalization turned on.

Reducing complexity one feature at a time: Active Assist expands to the console

Active Assist is a part of Google Cloud’s AIOps solution that uses data, intelligence, and machine learning to reduce complexity, optimize, and automate away the overhead of managing your cloud environment. Over the past few years, we have been helping you tackle various aspects of cloud complexity like securing your cloud resources, firewall configuration, managing idle resources, optimizing Cloud SQL and optimizing BigQuery for cost and performance, just to name a few examples. Today, we’re excited to introduce Quick Access, our first personalized experience powered by Active Assist:

In the context of Google Cloud, we see a couple trends that contribute to a continued increase in complexity. Development velocity and complexity of a typical enterprise environment have grown significantly, where engineering organizations need to regularly work across a large number of interconnected projects and sub-systems. Google Cloud has also added a number of new products and features to enable and support a wide range of workloads and use cases that our diverse customer base requires. The growth in Google Cloud creates a platform of nearly one hundred different product pages and thousands of corresponding sub-pages in the Google Cloud console. 

As a result, cloud users face difficulty navigating the Google Cloud console. Our research indicates the majority of users only visit a few pages per day while spending a considerable amount of time searching for their desired destinations. Quick Access aims to solve this challenge by surfacing your most relevant destinations on the homepage.

Behind the scenes: how Quick Access works?

At a high-level, Quick Access is powered by a machine learning model that calculates the probability of you navigating to a certain page based on Google Cloud usage – aiming to predict which pages you’d want to go to next.

The idea of intelligent navigation shortcuts is not new. For example, the Google Drive team introduced a similar concept in 2017. We are now applying this concept to Cloud Console, a different domain with its unique definition of what a “destination” is (e.g. Google Drive files vs. Google Cloud product pages), constraints, and other challenges such as making Quick Access suggestions aware of the common cloud usage/workflow patterns.

For those of you who have personalization turned on, Quick Access infers intelligent navigation suggestions based on the following Cloud Console usage data:

Your recently visited pages in Google Cloud

Anonymized workflow patterns for all users who also have personalization turned on

Built with privacy and security in mind

As with any Google product, privacy and security are baked into the design of the Quick Access feature. The data we use to train the underlying machine learning model doesn’t contain any personally identifiable information (PII), and is based on anonymized Cloud Console usage/workflow patterns only. For example, we will register the fact that you landed on a Compute Engine VM creation page, and then accessed a firewall management page, after scrapping your VM names or firewall configuration.

You are always in control of what you share with Google and can choose to opt out of personalization at any time by toggling off the appropriate controls for your organization under Google Cloud personalization and Web & App Activity settings.

Please note that if you choose to opt out of personalization, you will still see Quick Access as a part of your homepage experience. However, instead of having ML personalized suggestions, Quick Access will be based on a set of simple rules, potentially making it less relevant to your environment.

Try it today, let us know your thoughts!

With the firm belief that small things add up, we hope that you’ll find Quick Access to be a helpful tool for you to get to your intended destinations on Google Cloud in almost half the time, so that you can go home a bit earlier each day 😊. Please feel free to reach us at active-assist-feedback@google.com – we can’t wait to hear your feedback and thoughts about this feature and other ways we can help bring you the information you’re looking for!