CHAPTER 6

Cloud Functions and Cloud Run

In this chapter you will learn to

•  Determine when to use Cloud Functions and Cloud Run for Google Cloud Platform (GCP)

•  Deploy and implement Cloud Functions and Cloud Run resources

•  Determine best practices for traffic splitting, scaling, and versioning

Serverless Compute Options

Serverless computing allows a developer to focus on development activities, such as writing code, instead of having to worry about infrastructure and system maintenance. Some of the benefits serverless computing offers are zero server management, autoscaling, pay-as-you-go resource usage, and on-demand resource provisioning. You should consider using serverless computing solutions for systems that offer stateless HTTP applications, web and mobile applications, IoT and sensor-based applications, data processing solutions, and chatbots. With GCP, three platform offerings support serverless computing: App Engine, Cloud Functions, and Cloud Run. Each of the serverless compute options in the GCP portfolio has unique features. The differences between the three are defined as follows:

•  App Engine When you are looking to build a serverless application meant for use with a web or API-based backend, App Engine is a solid choice. App Engine supports key development languages without the need to worry about infrastructure support.

•  Cloud Functions Solutions that are event-driven and can easily extend to Google and third-party services best fit in this category. Applications that scale quickly best fit this description, too.

•  Cloud Run If you require a serverless compute platform that requires an application run in stateless containers, you are likely to find that Cloud Run is the best choice for your deployment. Cloud Run is fully managed, but also the pricing is based on consumption exclusively. Anthos, the GKE serverless container option built on Knative, an open source platform, is available for Cloud Run. Anthos allows for a mixed architecture using on-premises and cloud consumption.

In Chapter 5, you explored the capabilities of App Engine. This chapter focuses on serverless computing options that are not exclusive to web and API-based backends.

Cloud Functions

Cloud Functions are serverless. A big difference between App Engine and Cloud Functions is that App Engine supports the use of many services in a single application. Cloud Functions support individualized services. Each service is managed and operated independently from the other services. When you have an application that must communicate with multiple application services, such as a web application or one that leverages APIs, App Engine is a suitable choice. The inter-relationship among these services allows for an application to be treated as a managed entity.

If your compute requirements are not associated with multiple services, Cloud Functions should be considered. For example, if you are looking to save or extract data from a database, post a file to a specific storage location, or validate data in order to meet a business requirement, the use of Cloud Functions is likely more appropriate. Cloud Functions enable developers to focus on the activity itself. A developer would not need to worry about activities such as extraction, transformation, and load (ETL) with Cloud Functions in terms of communication among other services. The goal is specific to a single service. Cloud Functions time out after one minute, although the timeout can be extended up to nine minutes in total.

Events, Triggers, and Functions

Events occur when a particular action initiates within the Google Cloud Platform. Examples might include a message being written to the Pub/Sub message queue and documents being pushed to a storage repository. Actions are associated with a given event. GCP supports events in five categories: Cloud Storage, Cloud Pub/Sub, HTTP, Firebase, and Monitoring Logging. Table 6-1 illustrates the event categories and associated activities. Most events require some form of response. A trigger is the result of an event response, whereas a function is the response to the trigger. A function is when a data argument is passed to a given event.

Table 6-1 Cloud Functions Event Categories and Actions

Runtime Environments

Functions operate independently in their own environment. When a function is invoked, it runs in a separate instance from other function calls. Unlike in App Engine, where data is shared among application instances, once a function is invoked, it operates on its own. If you need to keep track of the data associated with the events processed, you should use a database or maintain a writable file in Cloud Storage. Currently, GCP supports three runtime environments: Node.js, Python, and Go.

In the following exercise, you will learn how to leverage a Cloud Function in the Cloud Pub/Sub category. Of all the categories, Cloud Pub/Sub is associated most often with Cloud Functions.

Exercise 6-1: Executing a Basic Cloud Function

Before you start creating a Cloud Function, make sure you have the Cloud Functions API and Cloud Pub/Sub API enabled in Google Cloud Console. The next steps can be completed using either the Cloud Console or the Cloud Shell/Cloud SDK. This exercise will use the Cloud Shell.

1. Update the components available by entering the following command:

2. Once the command is complete, establish your development environment:

This example uses the Node.js file:

3. Deploy the helloPubSub runtime. You should enter a name for the Pub/Sub message you would like to express in <YOUR_TOPIC >.

4. After deploying the event, you will want to try to trigger it:

In the example, you would enter:

5. Check to make sure the execution is complete:

6. Assuming you do not want to keep the instance and be charged for use of Cloud Functions and Pub/Sub, enter the following command line to delete these events, triggers, and functions from the system:

This exercise demonstrates how you can load an application from GitHub and deploy it using Node.js. The application, once deployed, allows you to submit two parameters: Project ID and Your Name. In the example, you only provided one. The event captures the data, and the trigger is the publishing of the message. In this case, the output is Hello, [email protected]. The function also allows for the log to produce the first 10 entries stored in the system. Once this exercise is complete, you delete the application.

Whether the code executed is intended for Cloud Storage, HTTP, Cloud Pub/Sub, or another category, the deployment process is the same except for the category parameter.

Cloud Run

Cloud Run is a serverless compute platform that is fully managed by Google Cloud. The difference between Cloud Run, App Engine, and Cloud Functions is that the Cloud Run platform can scale stateless containers, with emphasis on Kubernetes Engine. Because Cloud Run is serverless and abstracts all infrastructure responsibilities, you do not need to worry about application backend support.

Cloud Run is available in two variations. Cloud Run native fully embraces the Google Cloud Platform exclusively. Cloud Run for Anthos supports both Google Cloud and on-premises environment connectivity using Google Kubernetes Engine. Cloud Run is built on an open source application standard, Knative, which allows you to create portable applications.

Exercise 6-2: Deploying an Application in a Container Using Cloud Run

In order to deploy an app using Cloud Run, make sure you have the Cloud Build, Container Registry, and Cloud Run API enabled using Google Cloud Console. The next steps can be completed using either Cloud Console or Cloud Shell/Cloud SDK. This exercise will use Cloud Shell.

1. You first want to write the sample application code. Using the out-of-the-box script available in Google Cloud Platform for Python, a prerequisite for writing the application is creating the necessary directories. Therefore, enter the following into Cloud Shell:

2. You are now ready to create a basic application. You start by creating the data file that will house the script. To create the file, enter the following:

The following is the content you would enter into the .py file:

Notice the use of the PORT environment variable. The code responds to requests from the “Hello World” greeting. HTTP handling is done by an existing web server in the container. In this example, the Gunicorn server (https://gunicorn.org/) is utilized because GCP leverages Flask, a Full Stack Python web development framework. If you invoke the application locally, the output is a basic web server that listens to activity on the port.

3. At this point, your application can be containerized. Using a Python Dockerfile, you start a Gunicorn web server that listens to the portal environment variable. Enter the following on the command line to open the Python Dockerfile:

4. Enter the following code to prepare the application for deployment into the container:

5. After deploying the script, you may want to add a file. Add the .dockerignore file to exclude files from a container image. To exclude all files from being uploaded to Cloud Build, consider adding a .gcloudignore file.

6. Now that all parameters are in place, you should build the instances using Cloud Build. Here is the command to enter:

On the command line, you need to replace <project-id> with your project’s name and <application name> with the name of the application you’re building.

7. Your application is built. The last step is to deploy to Cloud Run. To deploy, enter the following command line:

8. During the deployment, you will be asked a few questions. The default response for each question follows:

•  The service name is the application name. In the sample script, it would be helloworld.

•  Select the region of your choice for the second prompt. Remember, these are regions, not zones. A sample region is us-east1.

•  Enter Y in the command line to allow unauthenticated invocation.

Your application is now deployed to Cloud Run.

Cloud Run for Anthos

If on-premises and container-based support are necessary to manage your serverless application, Cloud Run for Anthos is the best choice for you to consider implementing. Reasons why a developer would choose Cloud Run for Anthos over Cloud Run include the following:

•  Simplified development environment

•  Operational use of Google Kubernetes Environment

•  Serverless capabilities regardless of geography

•  Extended autoscaling capability

•  Allows for any runtime environment

•  Supports monitoring and workflows

•  Leverages container workflows and standard APIs, including Container Registry, Cloud Build, and Docker

•  Can utilize a custom domain for an application

•  Built on Knative, an open source platform allowing for application portability

•  Use of GPU/TPU-based compute capacity for larger deployments

The list of features is quite extensive, but it comes down to availability of enterprise features for on-premises and cloud-native capabilities.

Deploying Cloud Events

Cloud Events can be deployed using Cloud Console, Cloud Shell, or Cloud SDK. To fully utilize Cloud Functions, you must enable the Cloud Functions API or the Cloud Run API. If you decide to deploy an instance using Cloud Console, go to the navigation area and locate Cloud Functions under the Compute section (see Figure 6-1).

Figure 6-1 Cloud Functions and Cloud Run in Cloud Console Navigation

Cloud Events and Cloud Storage

Limited knowledge is required for managing Cloud Events using Cloud Storage. In later chapters, you will learn more about the types of storage to utilize. All files are stored in Cloud Storage, which utilizes buckets to add, update, delete, and archive files. You can manage all facets of the Cloud Functions life cycle with events using Cloud Storage.

Cloud Functions Deployment Using Cloud Console

To create a Cloud Function, you first need to enable the Cloud Functions API. Once it’s enabled, select the Cloud Functions menu option under Compute. You are prompted to initiate the process of creating a Cloud Function.

Once the Cloud Function is activated, a screen will appear that allows you to define the necessary parameters to create the Cloud Function, as shown in Figure 6-2.

You are asked to provide the following information:

•  Function name

•  Memory allocation

•  Trigger type

•  Source code location

•  Preferred runtime

•  Targeted function to execute

•  Environmental variables

Figure 6-2 Creating a Cloud Function using Cloud Console for Storage Events

You must fill out each field on the page to create and enable the Cloud Function. Of note, you can enter the function code as part of the in-line editor. If you choose to upload the code using a file format, make sure the upload matches the runtime environment selected. Upon Cloud Function creation, it will appear on the Cloud Functions dashboard page, as seen in Figure 6-3.

Figure 6-3 Cloud Functions dashboard example

Cloud Functions Deployment Using Cloud Shell and SDK for Storage Events

Building Cloud Functions using command-line tools requires the latest components to be enabled, including making sure all commands and libraries are installed. As previously demonstrated in Exercise 6-1, here is the command to ensure your data is up to date:

Runtime environments will be updated if you are told that an update is required, as shown in Figure 6-4. Should you have the latest updates, you are informed that in Cloud Shell or Cloud SDK, all components are up to date. GCP is continually updating the runtime environments; therefore, you may need to install an update if identified. The command for this is

Deciding what version of the components you want to install and ensuring it is updated can be completed using the following command:

The output of all available components appears in Figure 6-5.

For this example, you will install the following:

Figure 6-4 An update to the runtime environment is needed.

Figure 6-5 List of updated components

Once these prerequisites are covered, you will want to deploy your function. Recognize that using a function is not limited to just the command gcloud deploy. You must include other parameters to fully qualify the function and save the items correctly in storage. The parameters you can pass are detailed in Table 6-2.

Cloud Events and Cloud Pub/Sub

Cloud Pub/Sub triggers a message based on the conditions set forth by a function. An event produces the triggered action, named topic, by which there is an expected reaction. Cloud Pub/Sub can be deployed using Cloud Console, Cloud Shell, or Cloud SDK.

Cloud Events and Cloud Pub/Sub Using Cloud Console

There are several ways in which you can go about creating a Pub/Sub event using a Cloud Function within Cloud Console. The quickest way is to complete all activities from the Cloud Functions interface, like so:

1. Select the Cloud Functions menu.

2. You’ll then be prompted to enter the name and the required memory allocation.

Table 6-2 Cloud Functions Installation Parameters

Figure 6-6 Creating a new topic for a Cloud Function using Cloud Console

3. Select the Pub/Sub trigger.

4. If you already have a Pub/Sub trigger established, select the trigger. Otherwise, create a new trigger.

5. To create a new Pub/Sub trigger, you need to create a topic. Enter the topic name, as shown in Figure 6-6.

6. Fill in the remaining fields by selecting the runtime and parameters necessary for your Cloud Function.

7. Click Create.

8. Once your Pub/Sub event is created, verify that it works by going to the dashboard and selecting the drop-down menu that allows you to test the function (see Figure 6-7).

Figure 6-7 Test a Pub/Sub Cloud Function using Cloud Console

Cloud Events and Cloud Pub/Sub Using Cloud Shell or Cloud SDK

Like in the previous section on Cloud Storage, you are strongly encouraged to make sure all components are updated and installed properly before deploying a function using Cloud Pub/Sub.

You use gcloud functions, similar to other command lines, to deploy the Pub/Sub function. For Pub/Sub, the number of parameters you must attach to the command is limited. Requirements include the name of the runtime environment as well as the name of the function and the name of the topic triggering the function. The command line appears similar to the following:

Here are the three passed parameters you must provide data for:

•  Name of function

•  Name of runtime environment

•  Name of topic

If all three parameters are included, a Pub/Sub topic will trigger as expected.

Pub/Sub and Object Change Notification Events

The purpose of object change notification events is to notify an application when an object’s state has changed. Before Pub/Sub, the use of this legacy option was available to pass events to Cloud Storage buckets. Generally, Pub/Sub is the preferred approach, as it is easier to use, more flexible, and provides more capability than object change notifications.

Traffic Management

Cloud Functions traffic management is handled under the Network Settings section when you create a new Cloud Function. You have two choices:

•  Route only requests to private IPs through the VPC connector This is the default option. Only requests to RFC 1918 IP addresses are routed to a VPC network. The remaining requests are sent to the Internet.

•  Route all traffic through the VPC connector All outbound requests for the function are sent to the VPC network.

Cloud Run has several traffic management alternatives. The first way is to specify which revisions should receive traffic and at what percentage. The second method allows you to roll back to a previous revision, ultimately enabling the rollout of the revision. The third method is to split traffic among multiple revisions. The final method is to send all traffic to the newest revision.

The quickest and most efficient way to make these modifications, regardless of approach, is from the Cloud Functions or Cloud Run dashboard using Google Cloud Console.

Scaling and Versioning

Scaling capabilities are different between Cloud Functions and Cloud Run. With Cloud Functions, the max_instances parameter defines the degree to which your function can scale in response to an incoming request. If your application must scale, you do so by creating new instances for each of your functions since an instance can only handle a single request at a time. Many requests will result in a performance spike, creating many instances. For most applications, this is acceptable. However, there are instances where a certain number of connections may cause performance issues. Such is the case when you are using a database with a Cloud Function.

Cloud Run, on the other hand, uses revisions to automatically scale to the number of container instances necessary for the incoming requests. Three determinants should be considered when scaling with Cloud Run: CPU process capacity, concurrency settings, and maximum containers established. When thinking about budgetary constraints, you are strongly encouraged to limit the number of containers, as it can become costly to run concurrent open connections.

Choosing App Engine, Cloud Functions, or Cloud Run

Choosing between App Engine, Cloud Functions, Cloud Run, and Cloud Run for Anthos can be decided using nine technical areas. Figure 6-8 illustrates how you would go about choosing either App Engine, Cloud Functions, or Cloud Run using a flowchart approach that best serves organizational needs.

From a technical point of view, there are nine metrics to consider, each with specific capabilities for the type of application that is deployed:

•  Deployment type Delivery method to deploy your stateless application.

•  Scaling Identifies if scaling is possible, and if so, what method of scaling is enabled. Only Cloud Run for Anthos autoscales differently from a standard stateless application.

•  Runtime environment support Programmatic language support to deploy an application on Google Cloud Platform. Whereas Cloud Run and Cloud Run for Anthos support virtually all programmatic runtimes, App Engine and Cloud Functions have limitations.

•  Access controls Approaches to handle security and identity management for a stateless application using GCP. Each stateless application handles access control differently.

•  HTTP/gRPC Cloud Endpoints support for protocol transcoding that allows for access to your gRPC (Google RPC remote procedure calls) API via HTTP/JSON. Only Cloud Run with Anthos handles Cloud Endpoints management because of the mixed cloud and on-premises topology requirements.

Figure 6-8 Choosing between App Engine, Cloud Function, and Cloud Run

•  Custom domains Allows you to map to your domain name versus the GCP-branded domain that hosts the application. Standalone and container-based applications allow for custom domains. The Cloud Functions platform does not support custom domains.

•  GPU/TPU support Extends CPU capability using either graphics processing units (GPUs) or tensor processing units (TPUs) for extended memory and compute capacity. Only Cloud Run for Anthos extends CPU supports with GPU/TPU.

Table 6-3 Comparing Stateless Application Types

•  Timeout (minutes) The number of minutes before an application will quit if there is no activity. App Engine times out after one minute. Cloud Functions will time out after nine minutes. Cloud Run and Cloud Run for Anthos time out after 15 minutes.

•  VPC networking On-demand pool of shared computing resources available within a public cloud that allows isolation among organizations and their instances. All stateless applications except for Cloud Run allow for this capability. GCP does not have VPC networking available in general availability at this time.

Table 6-3 provides a technical comparison of the features that distinguish the four stateless application environment types.

Chapter Review

The chapter begins with you learning about the different options available in GCP with serverless computing. You can select from App Engine, Cloud Functions, Cloud Run, and Cloud Run for Anthos. App Engine is best suited for those looking for a serverless computing option that enables web application or API-based backend support. Cloud Functions are ideal for the event-, trigger-, and function-based delivery of applications in a serverless setting. Cloud Run, which also includes the use of Anthos, leverages containers to deliver serverless applications to users.

The next two sections of the chapter addressed deployment approaches for Cloud Functions and Cloud Run using Cloud Console, Cloud Shell, and Cloud SDK. Each deployment method allows for the use of the most popular programming languages, including Python, Node.js, and Go. For each deployment option, the use of events, triggers, and functions is allowed. Every deployment option has a specific set of parameters that can be used for events associated with Cloud Storage, Cloud Pub/Sub, and traffic management activities. Finally, throughout the chapter, you learned various command-line functions that can be used for Cloud Shell or Cloud SDK to work with Cloud Functions and Cloud Run for creating events, triggers, and functions in support of scaling, managing traffic, and versioning stateless applications.

Questions

1. You have been tasked with deploying a serverless web-based application that integrates a number of third-party APIs. The APIs are not hosted by your team. Rather, they are hosted by financial institutions and content aggregators. Which serverless platform would be the best option to deploy the web-based application?

A. App Engine

B. Cloud Functions

C. Cloud Run

D. Cloud Run for Anthos

2. An organization is looking to containerize its application. The team using the application is spread out across three continents. In order to optimize application performance, the IT administrators are evaluating the best approach to handle distributed containerization that also requires the use of some on-premises infrastructure resources. Which environment is best suited for the deployable stateless application?

A. App Engine

B. Cloud Functions

C. Cloud Run

D. Cloud Run for Anthos

3. The IT administrators at your organization are trying to troubleshoot specific system performance errors with their recently deployed stateless application. They’ve noticed that the application—a financial transaction solution that ingests and reviews tens of thousands of records a minute—continues to perform poorly at peak periods during the day. What would you recommend to the IT administrators?

A. Migrate the solution to Cloud Run for Anthos and apply GPU/TPU capacity.

B. Migrate the solution to Cloud Run and increase the timeout to the maximum threshold available.

C. Migrate the solution to Cloud Run for Anthos and apply VPC networking.

D. Migrate the solution to Cloud Run and switch to another programming language that has a smaller footprint.

4. Which of the following is not a true statement about event types?

A. There are five event type categories.

B. Events are action based, such as a file being uploaded or a message being queued.

C. Firebase events occur based on a function call.

D. Triggers are a method to respond to an event.

5. The DynaLearning team recently built a stateless application for payment processing. The developers have noticed that not all transactions are recognized, causing significant concern about system accuracy and reliability. What would you recommend the cloud administrator do to correct the loss of transactions?

A. Utilize a custom domain.

B. Use a database to record transactions of function activity.

C. Switch the application from a Cloud Functions environment to an alternative option.

D. Increase the timeout of the stateless application.

6. Which of the following runtimes are supported for both Cloud Functions and Cloud Run?

A. Node.js, Python, Java

B. Node.js, Python, Go, PHP

C. Node.js, Python, Go

D. All runtimes are supported for Cloud Functions and Cloud Run.

7. Which of the following environment types offers the longest timeout option?

A. App Engine standard environment

B. Cloud Functions

C. Cloud Run

D. App Engine flexible environment

8. You are looking to build your container using Cloud Build, which allows you to deploy your container named LMS-1 to Cloud Run. Which of the following statements will allow you to execute a container build for the eDynaLearn Project?

A. gcloud builds submit --tag gcr.io/LMS-1/edynalearn

B. gcloud run deploy --image gcr.io/LMS-1/edynalearn

C. gcloud run deploy --image gcr.io/edynalearn/LMS-1

D. gcloud builds submit --tag gcr.io/edynalearn/LMS-1

9. Under what conditions are you still charged to utilize Cloud Run when a project is not active?

A. When the image is stored in the Container Registry after the deployment

B. When you delete the image or your cloud project

C. When you delete all of the resources in a project

D. All of the above will result in no additional charge.

10. Which API(s) are required to build and deploy a Cloud Run or Cloud Run for Anthos instance?

A. Cloud Build and Container Registry

B. Cloud Build and Cloud Monitoring

C. Container Registry and Cloud Monitoring

D. Cloud Run, Container Registry, and Cloud Build

11. When you’re trying to autoscale an instance in Cloud Run, a revision is automatically scaled to handle the number of container instances. Which of the following is not a condition for autoscaling?

A. Amount of CPU needed to process a request

B. Concurrency setting

C. Type of storage used

D. Number of container instance settings

12. What is the key difference between Cloud Run and Cloud Run for Anthos?

A. Cloud Run and Cloud Run for Anthos have different timeout parameters.

B. Cloud Run for Anthos supports GKE, whereas Cloud Run does not require GKE support in a fully managed setting.

C. Cloud Run and Cloud Run for Anthos require the use of different types of programming language development environments.

D. Cloud Run does not support the use of custom domains, whereas Cloud Run for Anthos does support the use of custom domains.

13. Why might you choose not to use Cloud Run for traffic management?

A. Cloud Run allows you to split traffic on a percentage basis.

B. Cloud Run uses random traffic management as the default methodology.

C. Cloud Run allows you to maintain multiple configurations for a single route, or reference multiple versions during a rollout and n-way split.

D. Cloud Run allows you to assign traffic routes to addressable domains or any backing revision.

14. You are looking to deploy a stateless application. The application does not require the use of Kubernetes. The application requires the use of special libraries and a Java Runtime Environment. Which of the following options would best serve the team using Google best practices?

A. Cloud Run

B. Cloud Functions

C. Cloud Run for Anthos

D. App Engine standard environment

Answers

1. A. App Engine is appropriate for web- and API-based applications. Cloud Functions are appropriate for event-driven applications that also use third-party sources. However, in this case, the question does not discuss events, triggers, or functions. Cloud Run and Cloud Run for Anthos are intended for apps within containers or GKE.

2. D. Only Cloud Run supports containerization which eliminates all answers except for C and D. The difference between Cloud Run and Cloud Run for Anthos is the support for on-premises integration. Only the Anthos option supports a hybrid container approach.

3. A. Cloud Run alone does not allow for GPU/TPU support, which is the type of compute and memory performance optimization recommended in this question. Using Anthos does allow for GPU/TPU support. Nowhere in the question is there a recommendation on networking issues; this is a compute and memory-consumption issue.

4. C. Events occur based on triggers, not a function call. The remaining answer options are all correct statements.

5. B. If there is transactional activity associated with an event, trigger, or function, you should use a database to keep a record of your transactions. This is the only way to maintain a history without losing any data. Custom domains are not available for Cloud Functions, only App Engine and Cloud Run–based stateless environments. Switching to another environment does not solve the transactional activity capture issue, as there is still no living record of events and trigger-based activity. Increasing the timeout of the stateless application will not solve the problem.

6. C. Node.js, Python, and Go are available for both Cloud Functions and Cloud Run development environments. Java and PHP vary depending on environment. By default, answer D is incorrect because there are limits to the environments based on language.

7. C. Cloud Run and Cloud Run for Anthos offer a timeout of up to 15 minutes. App Engine offers a one-minute timeout. Cloud Functions offer a nine-minute timeout.

8. D. The difference among the four command lines has to do with two focal areas: the location of the project and application and the step in the process. You are being asked to build the containerized app, not deploy it. The command for deploying is gcloud run deploy. The command for building is gcloud builds submit. By elimination, that only leaves one choice based on the parameters of building a container and properly ordering the project and application.

9. A. Keeping one or more images in the Container Registry after a run will likely prompt additional utilization charges. On the other hand, deleting a project and all of the resources entirely will immediately result in no further charges. Therefore, answers B and C are incorrect. Also, given that answers B and C have been eliminated, answer D is therefore incorrect.

10. D. Building an instance of Cloud Run for Anthos requires the initiation of three APIs: Cloud Run, Container Registry, and Cloud Build. The Cloud Monitoring API is not required. Only answer D covers all three prerequisites.

11. C. The type of storage does not impact autoscaling configurations. All other parameters are influential in scaling.

12. B. Cloud Run for Anthos provides a flexible serverless development on GKE. Cloud Run is available as a fully managed serverless platform without requiring Kubernetes. Timeout parameters, development environments, and custom domain support are the same for both Cloud Run and Cloud Run for Anthos, making answers A, C, and D incorrect.

13. B. Random traffic management is not the most reliable solution suggested for Cloud Run. The other three options are all available alternatives for Cloud Run traffic splitting.

14. A. An application that requires environment support for Java and requires the use of special libraries is best suited for Cloud Run over App Engine or Cloud Functions. Since Cloud Run supports the use of special libraries and all programming language environments, it is the only answer choice that is feasible. The question explicitly states GKE is not necessary, thus eliminating Cloud Run for Anthos. The remaining two options do not fit the requirements because there are specific programming language support requirements and library requirements, which App Engine and Cloud Functions do not support.