SkarpChapter 15 of 26
Deploying Application Platforms: App Engine and Hybrid Architectures
Leverage App Engine alongside other compute services and connect frontends, backends, and data stores into cohesive application stacks.
App Engine in the Associate Cloud Engineer World
Why App Engine Matters
App Engine is a managed PaaS for web apps with autoscaling, versioned deployments, and easy integration with Cloud Storage, Cloud SQL, and Pub/Sub.
Exam View
On the Associate Cloud Engineer exam, App Engine tasks include deploying with gcloud, editing app.yaml, managing versions and traffic, and connecting to data services.
Standard vs Flexible
Standard uses language sandboxes with fast autoscaling and some limits; Flexible runs Docker containers on managed VMs with more control but slower scaling.
Link to Earlier Modules
Think of App Engine as a platform for full web apps, complementing Cloud Run (container HTTP services) and Cloud Functions (event-driven code).
Standard vs Flexible: Choosing the Right Environment
Standard Environment
Standard runs supported languages in sandboxes, with very fast autoscaling and simple config, but no custom runtimes or persistent local disk.
Flexible Environment
Flexible runs Docker containers on managed VMs, supports custom runtimes, more resources, and background processes, but scales slower and costs more.
When to Choose Standard
Choose Standard for typical web apps using supported runtimes, needing fast autoscaling, scale-to-zero, and tight integration with Google services.
When to Choose Flexible
Choose Flexible when you need custom runtimes, native libraries, or long-running background tasks that do not fit within Standard’s sandbox limits.
First Deployment: app.yaml and gcloud app deploy
Let’s walk through a minimal App Engine Standard deployment for a simple web app. The same patterns appear on the exam.
1. Enable App Engine and set region
- In the Console: App Engine → Create Application → choose region (cannot change later for that project).
- Or via `gcloud`:
```bash
gcloud app create --region=us-central
```
2. Minimal `app.yaml` for a Python 3 Standard app
```yaml
runtime: python310
service: default
handlers:
- url: /
script: auto
```
Key fields:
- `runtime`: which language/runtime (e.g., `python310`, `nodejs20`). Must be supported for Standard.
- `service`: logical service name (formerly “module”). If omitted, defaults to `default`. Services let you split your app into components (e.g., `frontend`, `api`).
- `handlers`: URL routing rules. For newer Python/Node runtimes you often use `script: auto`.
3. Deploy with `gcloud`
```bash
From the directory containing app.yaml
gcloud app deploy
```
What happens:
- A new version is created (e.g., `20260528t123456`).
- If this is the first deploy, it receives 100% traffic.
- The app is reachable at `https://PROJECTID.REGIONID.r.appspot.com`.
On the exam, pay attention to:
- Using the right project (`gcloud config set project PROJECT_ID`).
- Including `app.yaml` in the deploy command directory.
- Knowing that each deploy creates a new version, not overwriting the old one.
Versions, Services, Traffic Splitting, and Rollbacks
Services vs Versions
A service is a logical part of your app (default, api, worker). Each service has multiple versions, each representing a specific deployment.
Listing Versions
Use gcloud: `gcloud app services list` to see services and `gcloud app versions list --service=default` to see versions of a service.
Traffic Splitting
You can send percentages of traffic to each version, configured in the Console or via `gcloud app services set-traffic` with `--splits`.
Rollback Strategy
Rollback just means shifting 100% traffic back to a known good version; you do not need to redeploy old code to revert.
Design Exercise: Pick the Right Environment and Strategy
Work through these short scenarios and decide how you would deploy.
Scenario 1: Marketing site with traffic spikes
- Static+dynamic content, Node.js, sudden spikes during campaigns, cost sensitivity, no custom native libraries.
- Question: Would you choose App Engine Standard or Flexible? Why?
- Hint: Think about fast autoscaling and scale‑to‑zero.
Scenario 2: Image processing with native libraries
- Python app that uses OS‑level image libraries, runs CPU‑intensive tasks, needs background workers for long jobs.
- Question: Standard or Flexible? Why?
- Hint: Consider sandbox limitations and long‑running processes.
Scenario 3: Safe rollout of a new API version
- You have `default` service with version `v1` in production. You deploy `v2` with changed behavior.
- Question 1: How do you send only 10% of traffic to `v2`?
- Question 2: If error rates spike, what is the fastest rollback?
Suggested answers (compare with your own):
- Marketing site → Standard: supported runtime, bursty traffic, cost benefits and fast scaling.
- Image processing → Flexible: needs native libraries and long‑running background work.
- API rollout → Use traffic splitting (90% to `v1`, 10% to `v2`). To roll back, set 100% traffic back to `v1` using `gcloud app services set-traffic` or the Console.
Connecting App Engine to Cloud SQL Securely
Service Account Role
App Engine runs as a service account, which needs the Cloud SQL Client IAM role to connect securely to Cloud SQL instances.
Connection Pattern
You store DB credentials and the Cloud SQL instance connection name in env variables in app.yaml, then use the Cloud SQL connector in code.
Exam Clues
Watch for options using instance connection name and IAM roles; avoid designs that hardcode root passwords or use public IP without need.
Region Considerations
Place App Engine and Cloud SQL in the same or nearby regions to reduce latency and avoid cross-region data transfer patterns.
Integrating App Engine with Cloud Storage and Pub/Sub
Cloud Storage Pattern
App Engine writes files to a Cloud Storage bucket using the Storage client library, with bucket name in env variables and IAM roles on its service account.
Access Control
Grant only needed Storage roles (e.g., Object Creator for uploads) to the App Engine service account to follow least privilege.
Pub/Sub for Async Work
App Engine publishes messages to Pub/Sub topics; subscribers such as Cloud Run or Cloud Functions handle background processing.
Exam Strategy
For large uploads, store in Cloud Storage and send object metadata over Pub/Sub, not the file itself, to decouple storage and processing.
Hybrid Architecture: App Engine Frontend + Cloud Run + Cloud SQL
Tier 1: App Engine Frontend
Place the user-facing web frontend on App Engine Standard for fast autoscaling and simple HTTP deployment, as a service like `frontend`.
Tier 2: Cloud Run API
Run CPU-intensive or container-specific logic as a Cloud Run service `image-api`, which the frontend calls over HTTPS.
Tier 3: Cloud SQL
Use Cloud SQL as the shared relational database, accessed by both App Engine and Cloud Run through secure connectors.
Security and IAM
Use separate service accounts with Cloud SQL Client role and restrict Cloud Run ingress to internal or authenticated calls where possible.
Quick Check: Environments and Traffic
Test your understanding of environment choice and traffic control.
You run a Java web app on App Engine. You just deployed a new version `v2` of the `default` service and want 5% of users to hit `v2` while 95% continue using `v1`. What is the best approach?
- Redeploy `v1` and `v2` together with a new combined version that contains both behaviors.
- Use `gcloud app services set-traffic default --splits v1=0.95,v2=0.05` to configure traffic splitting.
- Delete version `v1` so that all traffic automatically goes to `v2`, then recreate `v1` if needed.
- Change the app.yaml of `v2` to include `traffic: 0.05` and redeploy.
Show Answer
Answer: B) Use `gcloud app services set-traffic default --splits v1=0.95,v2=0.05` to configure traffic splitting.
App Engine controls traffic at the service/version level, not inside app.yaml. To send 5% traffic to v2 and 95% to v1, you use traffic splitting: `gcloud app services set-traffic default --splits v1=0.95,v2=0.05`. Deleting v1 or redeploying combined versions is unnecessary and risky.
Quick Check: Secure Data Access
Check your understanding of secure connections from App Engine to data services.
An App Engine Standard app must write user-uploaded images to Cloud Storage and metadata to Cloud SQL. Which combination follows Google Cloud best practices?
- Give the App Engine service account Owner role on the project and connect to Cloud SQL via public IP with a hardcoded root password.
- Grant the App Engine service account Storage Object Creator on the bucket and Cloud SQL Client on the instance, and use the Cloud SQL connector with the instance connection name.
- Make the bucket public and let users upload directly, then have App Engine read the bucket anonymously and connect to Cloud SQL using a shared static password.
- Use a Compute Engine VM as a proxy: App Engine calls the VM, which then accesses Cloud Storage and Cloud SQL using its own credentials.
Show Answer
Answer: B) Grant the App Engine service account Storage Object Creator on the bucket and Cloud SQL Client on the instance, and use the Cloud SQL connector with the instance connection name.
Best practice is least-privilege IAM roles and managed connectors. Grant Storage Object Creator on the bucket and Cloud SQL Client on the instance to the App Engine service account, then use the Cloud SQL connector with the instance connection name for secure access. Avoid overly broad Owner roles, public buckets, or unnecessary proxy VMs.
Key Term Review: App Engine and Hybrid Architectures
Flip through these cards to reinforce key concepts before moving on.
- App Engine Standard environment
- A managed runtime environment using language-specific sandboxes with fast autoscaling, support for certain languages only, no custom runtimes, and limits on local disk and background processes.
- App Engine Flexible environment
- An App Engine environment that runs Docker containers on managed Compute Engine VMs, supporting custom runtimes, more resources, and background processes, with slower scaling and VM-like billing.
- App Engine service
- A logical component of an App Engine application (such as default, api, worker) that can have multiple versions, each representing a specific deployment of code and configuration.
- App Engine version
- A specific deployment of code and configuration for a given App Engine service. Each deployment creates a new version that can receive traffic independently.
- Traffic splitting
- An App Engine feature that lets you route a percentage of incoming traffic to different versions of the same service, supporting canary and blue/green deployments.
- Rollback in App Engine
- The process of moving traffic back to a previous stable version by updating traffic splitting, rather than redeploying old code.
- Cloud SQL connection name
- The identifier in the format PROJECT_ID:REGION:INSTANCE_ID used by the Cloud SQL connector and App Engine/Cloud Run to connect securely to a Cloud SQL instance.
- Hybrid architecture (App Engine + Cloud Run)
- A design where App Engine hosts the web frontend and Cloud Run hosts containerized backend or CPU-intensive services, both potentially sharing services like Cloud SQL and Pub/Sub.
- Cloud Storage integration pattern
- App Engine uses a service account with appropriate Storage IAM roles to read/write objects in a bucket, with bucket names and settings passed via environment variables.
- Pub/Sub integration pattern
- App Engine publishes messages to a Pub/Sub topic, while downstream services such as Cloud Run or Cloud Functions subscribe and perform asynchronous processing.
Bringing It Together and Next Steps in Your Path
What You Can Now Do
You can deploy to App Engine, configure app.yaml, manage versions and traffic, and integrate with Cloud SQL, Cloud Storage, and Pub/Sub.
Exam-Focused Patterns
Remember Standard vs Flexible trade-offs, secure data access using IAM and connectors, and using traffic splitting for safe rollouts.
Link to Your Study Path
Mock exams and diagnostics will reuse these patterns in scenario questions; your gap guide will highlight any weak areas for review.
Self-Check
Describe one ideal App Engine Standard use case and one hybrid design combining App Engine with Cloud Run, GKE, or Compute Engine.
Key Terms
- service account
- A service account is a special kind of account used by an application or compute workload, not a person, to make authorized API calls and access Google Cloud resources.
- Traffic splitting
- An App Engine feature that lets you route a percentage of incoming traffic to different versions of the same service, supporting canary and blue/green deployments.
- App Engine service
- A logical component of an App Engine application (such as default, api, worker) that can have multiple versions, each representing a specific deployment of code and configuration.
- App Engine version
- A specific deployment of code and configuration for a given App Engine service. Each deployment creates a new version that can receive traffic independently.
- Hybrid architecture
- An application design that combines multiple Google Cloud compute services (such as App Engine, Cloud Run, GKE, and Compute Engine) with shared data and messaging services like Cloud SQL, Cloud Storage, and Pub/Sub.
- Rollback (App Engine)
- The process of moving traffic back to a previous stable version by updating traffic splitting, rather than redeploying old code.
- Cloud SQL connection name
- The identifier in the format PROJECT_ID:REGION:INSTANCE_ID used by the Cloud SQL connector and App Engine/Cloud Run to connect securely to a Cloud SQL instance.
- Pub/Sub integration pattern
- A pattern where an App Engine app publishes messages to a Pub/Sub topic and downstream services such as Cloud Run or Cloud Functions subscribe and process those messages asynchronously.
- App Engine Flexible environment
- An App Engine environment that runs Docker containers on managed Compute Engine VMs, supporting custom runtimes, more resources, and background processes, with slower scaling and VM-like billing.
- App Engine Standard environment
- A managed runtime environment using language-specific sandboxes with fast autoscaling, support for certain languages only, no custom runtimes, and limits on local disk and background processes.
- Cloud Storage integration pattern
- A pattern where an App Engine app uses a service account with appropriate Storage IAM roles to read and write objects in a bucket, with configuration provided via environment variables.