Article 23 – Google App Engine

So you have written a web application. Maybe it is a Flask app in Python, or a Node.js Express server. And your goal is simple: “I just want to run my code and have it scale automatically without worrying about servers, operating systems, or patches.”

You do not want to manage VMs. You do not want to deal with Kubernetes. You just want to deploy your code and have Google handle everything else. That is App Engine — Google Cloud’s Platform-as-a-Service (PaaS) offering.

Standard vs. Flexible — Two Very Different Flavors

App Engine has two environments, and understanding the difference between them is critical because it affects cost, scaling behavior, and what your code can do.

App Engine Standard

This is the fast, opinionated, tightly controlled environment. You write your code in a supported language runtime (Python, Node.js, Java, Go, PHP, Ruby), and App Engine runs it in a lightweight, secure sandbox.

The magic of Standard:

  • Scale to Zero — If your app has no traffic, App Engine scales instances down to zero. You pay nothing. When a request comes in, new instances spin up in milliseconds. This is incredibly cost-effective for apps with spiky or unpredictable traffic.

The restrictions:
– You cannot SSH into the instance
– You cannot write to the local file system
– Network access is more restricted
– You are limited to the specific language versions Google provides

Choose Standard when: Your app uses a supported runtime and you want rapid scaling with minimal cost during idle periods.

App Engine Flexible

This is the “give me more control” option. Flexible takes your app, wraps it in a Docker container, and runs it on managed Compute Engine VMs.

Because it is container-based, you get:
– Any programming language or runtime (via custom Dockerfile)
– SSH into the VMs for debugging
– Writing to local disk for temporary processing
– Custom binaries and libraries

The trade-offs:
– Cannot scale to zero — At least one instance must always be running
– Scaling up is slower (minutes, not milliseconds) because it boots new VMs
– Higher baseline cost

Choose Flexible when: You need a specific language, library, or OS-level dependency that Standard does not support.

The Application Hierarchy

App Engine applications have a clear structure:

  • Application — One per project, in a single region. You set this once and it cannot be changed.
  • Service — Logical components. A simple app has one default service. A microservices app might have user-api, frontend, and admin-portal — each scaled independently.
  • Version — Every deployment creates a new immutable version. You might have v1 (stable) and v2 (testing).
  • Instance — The actual compute unit running your code. The autoscaler creates and destroys these.
The app.yaml Configuration File

This is how you tell App Engine what to do. It is a declarative blueprint that lives with your code.

Standard Environment example:

runtime: python312
instance_class: F2

automatic_scaling:
  max_instances: 10
  min_instances: 1
  target_cpu_utilization: 0.75

handlers:
- url: /static
  static_dir: static
- url: /.*
  script: auto

Flexible Environment example:

runtime: custom
env: flex

manual_scaling:
  instances: 2

network:
  name: default
Traffic Splitting — Built-In Canary Deployments

This is one of App Engine’s most powerful features. You have just finished v2 of your frontend with a new design. You are not ready to send all users to it. You want to test it safely.

With a single command, you can tell App Engine: “Send 90% of traffic to v1 and 10% to v2.”

# Split traffic between versions
gcloud app services set-traffic my-service \
    --splits=v1=0.9,v2=0.1

Output:

Setting the following traffic allocation:
  [my-service] v1: 0.9, v2: 0.1

Monitor error rates and latency on v2. If it looks good, gradually shift more traffic. If something breaks, instantly roll back to v1. Safe and easy deployments.

Common Pitfalls and Best Practices

Pitfall: Choosing Flexible just for a small feature, then paying for always-on instances.
Best Practice: Default to Standard whenever possible. Only switch to Flex when you have a hard requirement that Standard cannot meet.

Pitfall: Writing stateful code that tries to write to the local file system in Standard. It will fail.
Best Practice: Design your apps to be stateless. Store persistent data in Firestore, Cloud SQL, or Cloud Storage.

Pitfall: Not setting max_instances in app.yaml. A bug causing infinite retries means uncontrolled scale-up and a massive bill.
Best Practice: Always set a max_instances limit as a cost safety rail.

Pitfall: Services making synchronous, blocking calls to each other.
Best Practice: Decouple services using Pub/Sub for asynchronous communication.

Quick Reference
# Deploy your app
gcloud app deploy

# Open the deployed app in browser
gcloud app browse

# List all services
gcloud app services list

# List versions of a service
gcloud app versions list --service=default

# Split traffic between versions
gcloud app services set-traffic [SERVICE] --splits=v1=0.9,v2=0.1

# Delete an old version
gcloud app versions delete [VERSION] --service=[SERVICE]

# Tail application logs
gcloud app logs tail -s default

Related Posts