Compare App Engine and Cloud Run

This guide provides an introduction to Cloud Run for those who are familiar with App Engine. It covers the key similarities and differences between the Serverless platforms to help prepare for migration from either App Engine standard environment or App Engine flexible environment.

Overview

Cloud Run is the latest evolution of Google Cloud Serverless, building on the experience of running App Engine for more than a decade. Cloud Run runs on much of the same infrastructure as App Engine standard environment, so there are many similarities between these two platforms.

Cloud Run is designed to improve upon the App Engine experience, incorporating many of the best features of both App Engine standard environment and App Engine flexible environment. Cloud Run services can handle the same workloads as App Engine services, but Cloud Run offers customers much more flexibility in implementing these services. This flexibility, along with improved integrations with both Google Cloud and third-party services, also enables Cloud Run to handle workloads that cannot run on App Engine.

Comparison summary

While there are many similarities and differences between App Engine and Cloud Run, this overview focuses on the areas that are most relevant for App Engine customers getting started with Cloud Run.

Resource model

The Cloud Run resource model is very similar to App Engine, but there are some key differences:

• Cloud Run does not have a top-level Application resource, or the corresponding default service.
• Cloud Run services in the same project can be deployed to different regions. In App Engine, all services in the project are in the same region.
• Cloud Run uses the term Revision, instead of Version, to align with the Knative resource model.
• Cloud Run revision names use the format: SERVICE_NAME-REVISION_SUFFIX, where REVISION_SUFFIX is either auto-generated, or set using the --revision-suffix=REVISION_SUFFIX deployment flag.
• Cloud Run revisions are immutable, meaning that you cannot reuse names like you can with App Engine versions (using the --version=VERSION_ID deployment flag).
• Cloud Run service URLs are based on a Service Identifier that is automatically generated on the first deployment of the service. The Service Identifiers use the format: SERVICE_NAME-<auto-generated identifier>. The Service Identifier is unique, and does not change during the lifetime of the service.
• In Cloud Run, only the service URLs (SERVICE_IDENTIFIER.run.app and https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app) are exposed by default. To address a specific revision, you must configure a traffic tag. In App Engine, both the service and version URLs are exposed automatically.

Deployment and configuration

In App Engine, most configuration is done in the app.yaml that is included in every deployment. This simplicity comes at a cost, in that, while a few settings can be updated using the Admin API, most changes require redeploying the service.

While Cloud Run has the service.yaml configuration file, it is not used in the same way as the app.yaml. The Cloud Run service.yaml cannot be used when deploying from source, as one of the required elements is the path to the final container image. Also, the service.yaml conforms to the Knative spec, and can be difficult to read for those not familiar with Kubernetes-style configuration files. For more information on using the service.yaml to manage configuration, see the Cloud Run documentation.

For App Engine customers getting started with Cloud Run, using the gcloud CLI deployment flags aligns much more closely with the App Engine at-deployment configuration management.

To set the configuration when deploying new code in Cloud Run, use gcloud run deploy flags:

gcloud run deploy SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

While it is not necessary to use the configuration flags with every deployment (see Managing configurations), you can do so to help simplify configuration management.

In Cloud Run, you can also update the configuration without redeploying the source code using gcloud run services update:

gcloud run services update SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

As Cloud Run revisions are immutable, this command will create a new revision with the updated configuration, but will use the same container image as the existing revision.

Managing configurations

For App Engine deployments, all settings must be provided for every deployment, and any settings not provided are assigned default values. For example, take App Engine service-a, with versions using the app.yaml files shown below:

runtime: python39
service: service-a
instance_class: F4

runtime: python39
service: service-a

runtime: python39
service: service-a
instance_class: F4
default values:
..
..

runtime: python39
service: service-a
default values:
instance_class: F1
..
..

version1 is configured with instance_class: F4, while version2, which provided no value for instance_class, is configured with the default instance_class: F1.

For Cloud Run, any configuration settings provided are applied, but any that are not provided keep their existing values. You only need to provide values for settings that you want to change. For example:

gcloud run deploy service-a \
--cpu=4

gcloud run deploy service-a

service: service-a
vCPUs: 4
default values:
..
..

service: service-a
vCPUs: 4
default values:
..
..

In App Engine, deploying with no configuration settings creates a version using all default settings. In Cloud Run, deploying with no configuration settings creates a revision using the same configuration settings as the previous revision. For the first revision of a Cloud Run service, deploying with no configuration settings creates a revision using all default settings.

Configuration defaults

Entrypoint

When deploying from source, App Engine reads the entrypoint command from the entrypoint attribute in the app.yaml. If no entrypoint is provided, a runtime-specific default is used. Cloud Run uses Google Cloud's buildpacks when deploying from source, and some languages do not have a default entrypoint, meaning you must provide one or the build will fail. For example, Python buildpacks require either a Procfile, or specifying the GOOGLE_ENTRYPOINT build environment variable.

Please review the buildpacks documentation for any language-specific configuration requirements.

Scaling

While Cloud Run and App Engine standard environment share much of the same scaling infrastructure, Cloud Run has been streamlined to enable much faster scaling. As part of this streamlining, the configurable settings are limited to:

• Maximum concurrency
• Maximum and Minimum instances

For Cloud Run instances, the target CPU utilization is not configurable, and fixed at 60%. See the Cloud Run documentation for more details about autoscaling.

App Engine flexible environment uses the Compute Engine Autoscaler, so has very different scaling characteristics than both App Engine standard environment and Cloud Run.

Idle instance timeout

In App Engine, idle instances remain alive for up to 15 minutes after the last request finished processing. Cloud Run allows you to configure this behavior using CPU allocation. To get the same behavior as App Engine, set the CPU allocation to CPU always allocated. Alternatively, use CPU only allocated during request processing to have idle instances shut down immediately (if there are no pending requests).

Warmup requests

Cloud Run automatically warms up instances using the container entrypoint command, so you do not need to manually enable warmup requests, or configure an /_ah/warmup handler. If you have code that you want to run at instance startup, before any requests are processed, you can either:

• Configure your app to listen for requests
• Configure a custom startup probe

Static content

In App Engine standard environment, you can serve static content without using compute resources by serving from Cloud Storage, or by configuring handlers. Cloud Run does not have the handlers option for serving static content, so you can either serve the content from the Cloud Run service (same as dynamic content), or from Cloud Storage.

Cloud Run Invoker role

Cloud Run also offers the ability to control access to a service with Identity and Access Management (IAM). The IAM policy bindings for a service can be set using the gcloud CLI, Console, or Terraform.

To replicate App Engine behavior, you can make the service public by allowing unauthenticated requests. This can be set at deployment, or by updating the IAM policy bindings on an existing Service.

gcloud run deploy SERVICE_NAME ... --allow-unauthenticated

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member="allUsers" \
--role="roles/run.invoker"

Alternatively, you can choose to control who has access to the service by granting the Cloud Run Invoker IAM role which is configurable per-service.

gcloud run deploy SERVICE_NAME ... --no-allow-unauthenticated
gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

Environment variables and metadata

Both App Engine and Cloud Run have certain environment variables that are automatically set. The table below shows the App Engine environment variables, along with their Cloud Run equivalents. Cloud Run only implements a few environment variables, as compared to App Engine, but the data available from the metadata server is mostly equivalent.

Default environment variables

Common metadata server paths

What's next

• Quickstart: Deploy a web service with Cloud Run
• Is my app a good fit for Cloud Run?
• Migrate my App Engine custom domain to Cloud Load Balancing
• Other resources:
  • Migrate from App Engine to Cloud Run with Docker (Python: codelab, video, Java: codelab)
  • Migrate from App Engine to Cloud Run with buildpacks (Python: codelab, video, Java: codelab)