Cloud Run and App Engine

Cloud Run and App Engine are Google Cloud's fully managed serverless platforms for running applications without provisioning or managing servers. Both support automatic scaling, pay-per-use pricing, and integration with other Google Cloud services. However, they differ fundamentally in their execution model and flexibility.

App Engine is a Platform-as-a-Service (PaaS) offering that abstracts away the entire infrastructure. You deploy your application code (in supported languages: Python, Java, Go, PHP, Node.js, Ruby, or .NET) and App Engine handles everything from provisioning load balancers to scaling instances. It offers two environments: Standard Environment (sandboxed, faster scaling, lower cost) and Flexible Environment (runs in Docker containers, more customizability, but slower scaling). App Engine enforces a specific runtime contract — your application must conform to certain constraints, such as no writing to the local filesystem (except /tmp) and request timeouts of 60 minutes for Standard (or 24 hours for manual scaling tasks).

Cloud Run is a fully managed compute platform that runs stateless containers. You provide a container image (via Artifact Registry or Container Registry), and Cloud Run automatically scales it up and down based on traffic, including scaling to zero when there are no requests. It is built on Knative, an open-source Kubernetes-based platform, and offers more flexibility than App Engine because you can use any runtime, any library, and any binary that fits in a container. Cloud Run supports both HTTP requests and event-driven invocations (via Eventarc). Key constraints: containers must start a web server on the port defined by the PORT environment variable (default 8080), and requests must complete within 60 minutes (for Cloud Run services) or 15 minutes (for Cloud Run jobs).

When you deploy a container image to Cloud Run, the following steps occur:

Standard Environment: Your application runs in a sandboxed runtime provided by Google. The runtime includes a web server (e.g., Jetty for Java, Gunicorn for Python). App Engine automatically starts and stops instances based on scaling settings. You configure scaling via app.yaml:

Flexible Environment: Your application runs in a Docker container on Compute Engine VM instances. Scaling is slower (minutes vs. seconds) because it provisions VMs. Instances are managed by App Engine, but you have SSH access and can install custom software. Billing is per-hour of VM uptime, not per-request.

Cloud Run:

App Engine Standard:

App Engine Flexible:

Cloud Run:

Deploy a service:

gcloud run deploy SERVICE_NAME \
  --image IMAGE_URL \
  --region REGION \
  --concurrency 80 \
  --timeout 300 \
  --max-instances 10 \
  --min-instances 1 \
  --cpu-boost \
  --no-cpu-throttling

List services:

gcloud run services list --region REGION

Describe a revision:

gcloud run revisions describe REVISION_NAME --region REGION

App Engine:

Deploy an app:

gcloud app deploy app.yaml --version VERSION --promote

View logs:

gcloud app logs tail -s SERVICE

Update scaling:

gcloud app services update SERVICE --min-instances 1 --max-instances 10

Both Cloud Run and App Engine integrate with: - Cloud Build: for continuous deployment. - Cloud Monitoring: for metrics like request count, latency, and instance count. - Cloud Logging: for application and request logs. - Cloud Scheduler: for cron jobs (App Engine has built-in cron; Cloud Run uses Cloud Scheduler to invoke HTTP endpoints). - Cloud Tasks: for asynchronous task processing. - Cloud SQL: via VPC connector (Cloud Run) or App Engine's built-in connection (Standard uses unix socket; Flexible uses TCP). - Cloud Storage: for static assets. - Eventarc: for event-driven invocations (Cloud Run).

The ACE exam tests your ability to differentiate between Cloud Run and App Engine based on requirements such as:

A financial services company needs to process real-time transaction alerts. They use Cloud Run because each alert is a discrete event that triggers a container to run for a few seconds. The container, written in Go, processes the alert, updates a database, and exits. They set --max-instances=50 to control costs and --min-instances=1 to reduce cold start latency for the most critical alerts. They use Eventarc to route Pub/Sub messages to Cloud Run. The system scales to zero during low-traffic periods, saving costs. A common mistake is forgetting to set --no-cpu-throttling (or --cpu-boost) to ensure CPU is allocated during initialization, which reduces cold start time. The team also uses Cloud Run's concurrency setting to allow multiple alerts to be processed by a single instance, increasing throughput. They monitor concurrency and instance count to avoid hitting the max instances limit, which would cause request queuing.

A SaaS company hosts a Django-based web app for project management. They choose App Engine Standard because it provides automatic scaling, integrates seamlessly with Cloud SQL via unix sockets, and offers a free tier for development. They configure automatic_scaling with min_idle_instances: 0 and max_idle_instances: 1 to minimize cost. During peak hours, App Engine scales up to 20 instances. They use Cloud Tasks to offload long-running operations (e.g., report generation) because App Engine Standard has a 60-second request timeout for automatic scaling. The team accidentally set max_concurrent_requests too high (default 10), causing some instances to become overloaded and return 503 errors. They fixed it by reducing concurrency to 5. They also learned that App Engine Standard's /tmp directory is writable but ephemeral — they use Cloud Storage for persistent file storage.

A retail company uses App Engine Standard for their main e-commerce site (Python) and Cloud Run for a custom recommendation engine written in R (not supported by App Engine). The recommendation engine is stateless and receives HTTP requests from the main site. Cloud Run scales to zero when no recommendations are requested, saving costs. They use a VPC connector to allow Cloud Run to access a Redis instance for caching. The main challenge was ensuring low latency for the recommendation service — they set --min-instances=2 and --cpu-always to avoid cold starts. The exam scenario might ask: 'Which service should host a containerized application that needs to scale to zero and uses a custom binary?' The answer is Cloud Run.