So far, AlpinaShop's migration has taken the most conservative route: moving what was there onto virtual machines. It works, but Marta is still maintaining operating systems, writing startup scripts, versioning instance templates and watching for security patches. It is work that does not distinguish AlpinaShop from any other shop: nobody buys more backpacks because a server is well patched.

App Engine was Google Cloud's first service, launched in 2008, and it is still one of the fastest ways to get a web application into production: you upload the code, Google takes care of everything else — servers, scaling, load balancing, TLS certificates, deployments — and you pay for usage. In this lesson you will deploy AlpinaShop's Flask catalogue on App Engine, learn to control its scaling and its cost, split traffic between versions to do a canary deployment, connect to Cloud SQL and Cloud Storage, and finish with an honest assessment of why many teams today choose Cloud Run instead.

1. What a PaaS is and what disappears from your job
2. The standard environment and the flexible environment
3. Anatomy of app.yaml
4. Deploying AlpinaShop's catalogue
5. Versions, traffic splitting and canary deployment
6. Scaling types and their effect on cost
7. Services and routing with dispatch.yaml
8. Reaching Cloud SQL and Cloud Storage from App Engine
9. Environment variables and configuration
10. Logs and errors
11. Background work: Cloud Tasks and cron.yaml
12. Real limitations and why many teams today choose Cloud Run

Platform as a service means the provider manages everything below your code. Compared with what we did in 02-01:

The whole of lesson 02-01 — templates, managed groups, health checks, autoscaling, progressive updates — comes down in App Engine to one configuration file and gcloud app deploy. And you get HTTPS with your own domain for free, something that in Compute Engine will require a load balancer and a managed certificate (03-02 and 03-07).

What you pay for it: less control and more coupling. You do not choose the operating system, you do not install arbitrary packages in the standard environment, and app.yaml is a Google-specific format that works nowhere else.

One organisational detail that surprises people: one App Engine application per project, and its region is chosen when the application is created and cannot be changed. If you get it wrong, you have to create a new project. For AlpinaShop, europe-west1, consistent with everything else.

App Engine has two environments that behave very differently under the same name:

When to use each. The standard environment is the natural choice for web applications in a supported language: it starts fast, scales to zero and is cheap. The flexible one makes sense if you need a system dependency the sandbox does not allow, your own binary or an unsupported language.

And here is the honest assessment that anticipates section 12: if you are thinking about App Engine flexible, Cloud Run is almost always the better option today — it also runs your container, but it scales to zero, is billed per request and is not tied to the App Engine format.

AlpinaShop uses the standard environment with Python 3.12: the catalogue is pure Flask with dependencies installed via pip, with nothing exotic.

app.yaml is the file that describes the whole application. Let us build AlpinaShop's while commenting on each block.

Three ideas from this file worth holding on to:

• Static-type handlers are free in CPU time. Google serves those files from its own infrastructure, without starting or occupying an instance. Serving CSS, JS and images that way instead of through Flask reduces cost and latency noticeably.
• secure: always should be on every handler. It redirects HTTP to HTTPS automatically.
• max_concurrent_requests is the biggest lever on cost. If your application spends most of its time waiting for the database, it can handle many simultaneous requests per instance; raising this value reduces the number of instances needed. If the application is CPU-bound, raising it makes latency worse.

Alongside app.yaml go the usual files of a Python project:

The .gcloudignore is no minor detail: without it, you would upload the .git directory and the entire virtual environment, with slow deployments and the very real risk of publishing an .env file with credentials.

The application, with the pieces we already know from the previous lessons:

Note pool_size=2. It is a deliberate change from the previous lesson: App Engine can create dozens of instances at a peak, and each one would open its own pool. With pool_size=5 and 20 instances that would be 100 connections from the catalogue alone. In environments that scale aggressively, pools must be small.

Notice GAE_VERSION too: App Engine injects environment variables with information about the runtime environment (GAE_SERVICE, GAE_VERSION, GAE_INSTANCE, GOOGLE_CLOUD_PROJECT). Showing the version on the page is a very practical trick for verifying deployments and traffic splits.

Deployment:

When you deploy, App Engine builds the package, installs the dependencies from requirements.txt, creates a new version and — unless you say otherwise — sends it 100 % of the traffic. The default URL is https://<projectId>.<region>.r.appspot.com, with a valid TLS certificate from the very first second and without you having configured anything.

Always use --version with a meaningful name. Without it, App Engine generates a timestamped identifier that is hard to read in the version list and in the traffic-splitting commands.

Every deployment creates an immutable version that stays available. This enables something very powerful: splitting traffic between versions.

The URL with the <version>-dot-<service>-dot-<project> prefix is a very useful detail: any deployed version is directly reachable, which lets you validate in the real environment before directing users to it.

On the splitting criterion, there are two modes and the difference matters:

For a canary of a user interface, cookie is almost always the right thing: with random, a customer could see one page on the old version and the next on the new one, with bewildering results.

And a cost warning: old versions with minimum instances configured keep billing even if they receive no traffic. Clean up periodically:

App Engine standard offers three scaling modes, and choosing badly is the main source of unexpected bills.

The cold start problem. With min_instances: 0 you pay nothing when there is no traffic, but the first request after a period of inactivity has to wait for an instance to start: loading the interpreter, importing the dependencies, opening the connection pool. In Python with Flask it is usually 1–3 seconds; if the code imports heavy libraries, longer.

The solution is to reserve warm instances:

And here is the trade-off, with indicative figures:

Indicative figures for reasoning about the order of magnitude. Check the official Google Cloud calculator.

AlpinaShop's decision, consistent with its reality: on alpinashop-dev, min_instances: 0 — Dani does not mind waiting two seconds and the environment spends the night with no traffic. In production, min_instances: 1 and max_instances: 10, because a customer who sees the shop take three seconds to load is a customer who leaves. During the autumn campaign the minimum goes up to 3 and the maximum to 20.

Additional tips for reducing cold starts: import heavy libraries lazily, do not do expensive work at module import time, and keep requirements.txt free of dependencies you do not use.

An App Engine application can have several services (previously called modules), each with its own app.yaml, its own scaling and its own versions. It is the way to separate components with different profiles.

For AlpinaShop:

Each service has its own URL (https://api-dot-alpinashop-prod.ew.r.appspot.com). To serve them all under a single domain with different paths, you use dispatch.yaml:

Advantages of separating services: each one scales according to its own load (the administration panel does not need 10 instances just because there is a peak in the shop), they are deployed independently, and a failure in the panel does not bring down the catalogue. It is a separation of failure domains, the same idea we applied to zones in 01-05.

Bear in mind that the rules in dispatch.yaml are evaluated in order and only a limited number are allowed; for complex routing you use a load balancer (03-02).

Here you see the value of having used client libraries in the previous lessons: the code does not change.

Every App Engine application has a default service account, <projectId>@appspot.gserviceaccount.com. It is enough to give it the right permissions:

With that, the same storage.Client() and the same Cloud SQL connector from lessons 02-02 and 02-03 work without touching a line, because the Application Default Credentials now resolve to App Engine's service account.

One peculiarity of the standard environment: the file system is read-only except for /tmp, which additionally lives in memory and counts against the instance's memory. Never store anything there that has to persist, nor large files. Images uploaded by users go straight to Cloud Storage, exactly as we programmed in 02-02 with upload_from_file over the stream.

Non-sensitive variables go in app.yaml, under env_variables. Sensitive ones do not: app.yaml ends up in the Git repository and its values are visible to anyone who can see the version's configuration.

The correct pattern is to read the secrets at start-up from Secret Manager:

To distinguish environments, the usual approach is to have one app.yaml per environment (app-dev.yaml, app-prod.yaml) and deploy the appropriate one:

The full detail of Secret Manager, secret rotation and encryption with Cloud KMS is in lesson 03-06.

App Engine automatically sends the requests, and everything the application writes to standard output, to Cloud Logging. Nothing needs configuring.

For the logs to be genuinely useful, write them structured as JSON: Cloud Logging indexes them by field and you will be able to filter by sku or by severity instead of searching for strings.

Uncaught errors arrive automatically in Error Reporting, which groups them by stack trace, counts occurrences and can warn you when a new error appears. It is one of the most profitable things the platform offers with no configuration at all.

The in-depth treatment of Cloud Logging, metrics and traces is in 06-06 and 06-04.

An HTTP request must not do long work: the user is waiting, and under automatic scaling there is a 10-minute limit. When AlpinaShop confirms an order, an email has to be sent, the stock updated and the warehouse notified; none of that should block the response to the customer.

Cloud Tasks is a managed queue: you enqueue a task, which consists of a deferred HTTP request to your own application, and the service delivers it with retries and rate control.

Two critical points here: checking the X-AppEngine-TaskName header as an access control, and idempotency. Cloud Tasks guarantees at least once delivery, not exactly once: if your handler is slow and there is a retry, you could send two emails or deduct the stock twice. Record which orders you have already processed and check before acting.

Cron. For scheduled tasks, cron.yaml invokes a URL of your application on a schedule:

The endpoints invoked by cron receive the X-Appengine-Cron: true header, which is checked just like the Tasks one. Protect those routes with a login: admin handler in app.yaml as well.

The equivalent service outside App Engine is Cloud Scheduler, which can invoke HTTP, Pub/Sub or Cloud Functions and works with any compute service. It is the option to use if your application does not live on App Engine.

App Engine is still a good product and there are applications that have been running on it for more than a decade without incident. But it is worth being honest about its limits in 2026:

• Coupling to Google's format. app.yaml, dispatch.yaml and cron.yaml do not exist outside App Engine. Migrating to another provider — or even to another Google service — means redoing the configuration.
• Limited runtimes on their own timetable. Only the languages and versions Google supports; when a Python version becomes obsolete, you have to migrate on Google's schedule.
• A restrictive sandbox in the standard environment. No custom binaries, system dependencies or writing to disk.
• The flexible environment has been left behind. It starts in minutes, does not scale to zero and costs more than container-based alternatives.
• Immutable region and one application per project. Rigid for architectures that evolve.
• The investment does not compound. Time spent mastering app.yaml is of no use anywhere else; time spent mastering containers is of use everywhere.

Cloud Run (lesson 07-02) occupies that space today: it runs your container, scales to zero, is billed by usage, offers traffic splitting between revisions just like App Engine, automatic HTTPS, and what you deploy is a standard container image that would also run on GKE, on your laptop or on another cloud.

When App Engine still makes sense: you already use it and it works; you want the shortest route from Python code to a URL with HTTPS; you do not have containers and do not fancy learning them right now; or you specifically need dispatch.yaml and the built-in cron.

When to choose Cloud Run: a new project, you already work with containers, you want portability, or you need control over the execution environment.

For AlpinaShop, the decision we will document in 02-07 is to start with Compute Engine (lift-and-shift, already done) and evolve towards containers. App Engine remains an option that is known and rejected for reasons, which is the best way to reject something.

• Creating the application in the wrong region. It is irreversible: it demands a new project. Check before gcloud app create.
• Deploying without .gcloudignore. Slow deployments and the risk of uploading .env or .git.
• Forgetting --no-promote when testing. You will send 100 % of the traffic to an unvalidated version.
• Using --split-by=random for an interface canary. The user sees different versions on consecutive requests.
• Leaving old versions with min_instances > 0. They bill without receiving traffic.
• Setting min_instances: 0 in production without measuring. The cold start eats your conversion rate.
• Large connection pools. Multiplied by many instances, they exhaust Cloud SQL's max_connections.
• Storing files on the local file system. Only /tmp, in memory and ephemeral.
• Secrets in env_variables in app.yaml. They end up in Git. Use Secret Manager.
• Non-idempotent Cloud Tasks handlers. Delivery is at least once.
• Serving static files from Flask. Use static_dir handlers: they are faster and consume no instances.
• Tip: put secure: always on every handler.
• Tip: use --version with readable names.
• Tip: show GAE_VERSION in the application so you can tell at a glance which version served each request.
• Tip: always set max_instances. It is your emergency brake against an abnormal peak or an attack.

1. Create the App Engine application in europe-west1 on alpinashop-dev.
2. Write a minimal Flask application that shows "AlpinaShop" and the version (GAE_VERSION), with a /salud route.
3. Write an app.yaml with the python312 runtime, class F1, automatic scaling from 0 to 4 instances and a static handler for /estatico.
4. Deploy it as version v1 and check the URL.
5. Explain what you would change in app.yaml for production and justify the associated cost.

1. Modify the application to show prices including VAT and deploy it as v2 without sending it traffic.
2. Check v2 on its specific URL.
3. Send 20 % of the traffic to v2 with cookie-based splitting.
4. Check the split by making several requests and observing the version shown.
5. Simulate a failure and perform a full rollback to v1. Then clean up the versions with no traffic.

1. Create a second service api with its own app.yaml and its own scaling, exposing /api/pedidos.
2. Write a dispatch.yaml that sends /api/* to the api service and everything else to default.
3. Add a cron.yaml with a daily task at 3:00 (Madrid time) that calls /tareas/exportar-pedidos on the api service.
4. Protect the cron endpoint by checking the corresponding header.
5. Explain why a task handler must be idempotent and how you would guarantee it for sending an order confirmation email.

Solution 1

For production I would change to instance_class: F2 (more memory for the connection pool and the client libraries), min_instances: 1 to remove the cold start for the first customer, and max_instances: 10 to absorb the autumn peaks. The added cost is that of keeping one F2 instance running 24 hours a day, on the order of €30–40 a month: a small figure compared with the value of the shop's front page always loading in under a second. It is worth checking the amount in the official calculator before committing.

Solution 2

With --split-by=cookie, if you keep the cookie between requests you will always see the same version: that is the desired behaviour, so as not to bewilder the user. Without a cookie — as in the curl loop above, where every call is a new session — the split behaves as random, and around 2 in every 10 responses will show v2.

Solution 3

5. The handler must be idempotent because Cloud Tasks guarantees at least once delivery: if the handler takes longer than expected, if it returns a transient error or if the instance is recycled halfway through, the task is retried and the same order arrives twice. With no protection, the customer would receive two confirmation emails and the stock would be deducted twice.

The way to guarantee it for the confirmation email is to record the fact transactionally in the database:

The key is the ON CONFLICT DO NOTHING on a primary key: the database guarantees that only one execution manages to insert the row, and the others exit without sending anything. Returning 204 on the second attempt also avoids infinite retries.

You have seen what going up a level of abstraction really means. In App Engine the operating system, the patches, the web server, the load balancing, the TLS certificates, the health checks and the instance templates all disappear: everything that filled lesson 02-01 comes down to an app.yaml and a gcloud app deploy. You know the decisive difference between the standard environment — sandbox, start-up in seconds, scaling to zero, cheap — and the flexible one — containers, start-up in minutes, no scaling to zero — and you know that the flexible one has today been displaced by Cloud Run.

You have dissected app.yaml line by line: runtime, entrypoint, instance class, scaling policy, environment variables and handlers, including the idea of serving static files from Google's infrastructure so as not to spend instances. You have deployed AlpinaShop's Flask catalogue and obtained a URL with HTTPS without configuring anything. You have learned to deploy with --no-promote, validate on the version's URL, split traffic with cookie affinity for a canary and roll back with a single command: deployment practices that in Compute Engine required versioned templates and progressive updates. You have understood the three scaling modes and the central trade-off between min_instances: 0 and the cold start, with AlpinaShop's reasoned decision: zero in development, one in production, three during the campaign. You have separated services with dispatch.yaml so that the administration panel and the catalogue scale independently, you have connected Cloud SQL and Cloud Storage without changing a line of code thanks to the default credentials, you have read secrets from Secret Manager at start-up, you have seen structured logs and Error Reporting, and you have moved the heavy work out of the request with Cloud Tasks and cron.yaml, learning along the way what at least once delivery means and how to write an idempotent handler.

And you have finished with an honest assessment: App Engine is convenient but coupled to Google's format, and the investment you make in it does not compound outside it. The alternative that does compound is containers. In 02-05, Google Kubernetes Engine, we will take that step: we will go over Kubernetes from scratch — container, pod, Deployment, Service, node and control plane — compare the Autopilot and Standard modes, create the alpinashop-cluster cluster, build and publish the catalogue image in Artifact Registry, write the Deployment and Service manifests, scale with a HorizontalPodAutoscaler and do updates with no interruption together with their rollback. It is the level of abstraction with the most power and also the most responsibility in the whole module.