Wesley Chun (@wescpy)

Posted on Oct 22

Hosting apps in the cloud with Google App Engine in 2024

#python #webdev #googlecloud #serverless

TL;DR:

If you're looking to put code online today, you have many options, with a VM or Kubernetes as the best choice for some. Others with less code may consider (AWS) Lambda. There are also options where developers don't have to consider traditional servers... these are known as serverless (compute) platforms. Google has several serverless options, and while Google is encouraging developers to go straight to Cloud Run, it would be remiss not to start the conversation with their "OG" serverless platform, App Engine, as it still does a few things that Cloud Run can't or won't do.

[IMAGE] Serverless computing with Google

Introduction

Welcome to the blog focused on using Google APIs, developer tools, and platforms, primarily from Python, but also sometimes Node.js. Here, you'll see me cover everything from to AI/ML on Google Cloud/GCP to Google Maps to YouTube to Gemini, and also nut-n-bolts like API key, and OAuth client ID credentials, especially for Workspace/GWS APIs like Google Docs and Google Sheets. The aim is to provide something for everyone.

The purpose of this post is to directly address the question, "Where can I host my app in the cloud?" More specifically, "How can I do so with the least amount of setup and friction?" The answers to both will almost always point to serverless, a subset of cloud computing focused on logic-hosting.

Serverless computing and logic-hosting

"Logic" means any code, whether a short code snippet to a web app to a container running a service. So "logic-hosting" is an all-encompassing term that includes app-hosting (hosting your apps in the cloud), function-hosting (hosting your functions in the cloud; FaaS), and container-hosting (hosting your containers in the cloud; CaaS).

All of that hosting can be accomplished with serverless computing, the ability to host that logic without thinking about or being concerned with servers, virtual machines or bare-metal. It's a bit of a misnomer because of course there are servers, but they've been abstracted away from users. Developers only need to focus on building their solutions, not what they run on. Learn more in the serverless post linked up at the top.

Background

When learning a new platform, it's a good idea to get an idea of what you're getting yourself into. Learn about how it started, how it worked, what languages were supported, etc., then be caught up to what the platform looks like today. If you don't care about any of this background and want to get your Python apps running on the cloud immediately, skip the next two sections.

^How it started ("Gen1")

Google App Engine (GAE) is their original serverless solution and first cloud product, launching in 2008 (video), giving rise to Serverless 1.0 and the cloud computing platform-as-a-service (PaaS) service level. It didn't do function-hosting nor was the concept of containers mainstream yet. GAE was specifically for (web) app-hosting (but also supported mobile backends as well).

One key innovation the GAE team brought to the market is a platform that handles the corner case of an app "going viral." Its ability to autoscale made it popular with social & gaming apps as well as those for special events like royal weddings where even in 2011, the platform was able to process 42,000 requests per second (qps) at peak traffic. That's in addition to handling "normal" apps.

Besides scalability, most applications need additional resources like a database ("Datastore"), caching ("Memcache"), blob/file object storage ("Blobstore"), external task execution ("Task Queue"), etc., so the team provided those too, providing a platform that gave developers all the tools they needed as well as the ever-challenging feature of autoscaling. That said, the platform still faced challenges:

Its strength is also its weakness: While it was handy to have your developer tools "just an import away" without 3rd-party installs & management, etc., use of GAE's bundled services like Datastore and Memcache, meant your app can only run on GAE. There is no portability when using services custom-made for the platform. This always became a sore point whenever the GAE team made their infrequent price increase announcements.
Untimely language upgrades: Concerted time, effort, and resources from the GAE team are required for any language upgrade, including support for new languages. It took five (5) years to upgrade from Python 2.5 to 2.7 (2013). It also took 5 years before PHP (PHP 5) support came around, even though it was the most requested language as the platform's highest "starred" feature request. Python 3.0 was released in 2008, the same year as GAE, and that seemed even further off, even as the world pivoted towards it.
Lack of container support: If GAE didn't support your language, tough luck. How can you wait for something when you don't know when support would come, or if at all? What about binaries or special libraries? No to those too. While the rise of Docker meant some developers were able to work around platform language support, containers weren't supported by GAE either.

These were problems that the GAE team would start to address, but not until 2018, a decade after platform launch.

📝 App Engine Flexible introduced for containers
While out-of-scope for this post, readers should know a sibling platform was introduced to run containers in 2014 Originally called "Managed VMs," it was renamed as App Engine Flexible in 2016. Most container and GAE Flexible use cases are now supported by Cloud Run.

^How it's going ("Gen2")

The next-generation platform ("Gen2") arrived in 2018, bringing about upgraded language versions like Python 3, Java 11, and PHP 7, as well as completely new languages to the platform like Ruby and Node.js. That was the good news. The bad news: no more bundled services..., or perhaps that's good news too. Users were no longer "locked in" and got to choose their own database, memcache server, etc. This made apps much more easily portable to other platforms.

While new users now have choices and can avoid "lock-in," existing users have a choice: either stay on old language versions to stay on "Gen1", or migrate off the bundled services and finally be able to upgrade from Python 2.7 to 3.7. Similarly, many of GAE's original bundled services, or "APIs" as they were known back in the day, had matured to being their own standalone GCP product.

Migrating off the bundled services which apps completely rely on was and still is a big challenge for developers. Not only are there language differences between major versions, but there's also a move from each bundled service to the comparable GCP equivalent. Adding to the complexity is that not all bundled services had newer Cloud replacements. At this point, many developers might as well rewrite their apps completely.

To further add to the complication, newer language releases like Python 3 only run on Gen2 while only Python 2 is supported by Gen1, meaning in order to upgrade, developers had to do both non-trivial migrations (2.x to 3.x and bundled to non-bundled services). While Google provided basic migration guides, they weren't enough for users, and as a result, few developers moved to Gen2.

It took another few years, but the GAE team finally addressed this conundrum with two major releases in 2021:

More comprehensive migration content: Interestingly around the time of pandemic lockdowns, I was brought back onto the GAE team to produce "before" (Gen1) and "after" (Gen2) code samples and hands-on tutorials ("codelabs") guiding developers through each bundled service migration. This also included an accompanying video series (direct YouTube playlist).
Re-enabling most bundled services: Bundled services support was added to Gen2 runtimes that had Gen1 runtimes, meaning only Python, Java, PHP and Go. Gen2 languages such as Ruby and Node.js didn't have Gen1 runtimes, and as such, did not "re-gain access to the bundled services" that they never had. If interested, see the documentation on accessing bundled services from Python 3 (and other Gen2 runtimes).

These launches were significant because they not only provided more developer guidance, but it broke the requirement that developers had to make both challenging language upgrade and pivot from bundled services migrations. Developers can just do the language migration, meaning upgrade from Python 2 to 3 (plus Java 8 to 11/17/20, etc.) and run their apps on Gen2 until they're ready to migrate off the bundled services.

⚠️ ALERT: Cost: billing required (but free?!?)

While many Google products are free to use, GCP products are not. In order to run the sample apps, you must enable billing and have active billing supported by a financial instrument like a credit card (payment method depends on region/currency). If you're new to GCP, review the billing and onboarding guide. Billing wasn't mandatory to use GAE in the past but became a requirement in 2019.

The good news is that GAE (and other GCP products) have an "Always Free" tier, a free daily or monthly usage before incurring charges. The GAE pricing and quotas pages have more information. Furthermore, deploying to GCP serverless platforms incur minor build and storage costs.

Cloud Build has its own free quota as does Cloud Storage (GCS). For greater transparency, Cloud Build builds your application image which is than sent to the Cloud Container Registry (CR) or Artifact Registry (AR), its successor. Storage of that image uses up some of that GCS quota as does network egress when transferring that image to the service you're deploying to. However you may live in a region that does not have a free tier, so monitor storage usage to minimize potential costs. (Check out storage use and delete old/unwanted build artifacts via the GCS browser.)

With the above said, you may qualify for GCP credits to offset any costs of using GCP. If you are a startup, consider applying for the Google Cloud for Startups program grants. If you are a higher education student, faculty member, researcher, or are an education technology ("edtech") company, explore all the Google Cloud for education programs.

Getting started

Let's look at a "Hello World!" app to show you how easy the platform is to use. The shortest/smallest app or "MVP" (minimally-viable product) requires just three (3) files:

GAE configuration
3rd-party requirements
Main application

Both samples are available in the repo for this post. Let's walk through each code sample, run locally, then do some GCP setup and deploy to GAE; Python first.

Python

The GAE configuration file is (always) named app.yaml (repo link), and while many options are available, an MVP only requires specifying the language runtime ID. In this sample app, I set it to Python 3.12:

runtime: python312

Python's requirements.txt file (repo link) is used for specifying all 3rd-party libraries, and in this case, it's just the Flask micro web framework:

flask

Name the main application file anything you want; I settled on main.py (repo link), shown here:

from flask import Flask

app = Flask(__name__)

@app.route('/')
def root():
    return 'Hello World!'

# local-only
if __name__ == '__main__':
    import os
    app.run(debug=True, threaded=True, host='0.0.0.0',
            port=int(os.environ.get('PORT', 8080)))

The Flask library is imported, then the Flask app instantiated. The only route in this app is to '/' which returns 'Hello World!' from the (default) GET request (browser, curl, etc.). You can name route functions anything you like, such as main() or index() -- I often use root(). The last few lines are only for running this app locally... drop this section entirely if only deploying to the cloud. It uses the os module to read the PORT environment variable and fires up the Flask "devserver" (development server) on port 8080 if PORT isn't set.

Now run the script to test the app locally; your (terminal) output should look something like this:

$ python3 main.py
 * Serving Flask app 'main'
 * Debug mode: on
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on all addresses (0.0.0.0)
 * Running on http://127.0.0.1:8080
 * Running on http://172.20.20.20:8080
Press CTRL+C to quit
 * Restarting with watchdog (fsevents)
 * Debugger is active!
 * Debugger PIN: 135-387-333

With a running server, point a web browser to http://localhost:8080:

[IMAGE] "Hello World!" sample app running locally (Mac)

In your terminal, you'll see log entries for each HTTP request:

127.0.0.1 - - [05/Dec/2023 15:42:55] "GET / HTTP/1.1" 200 -

To exit the devserver, issue a ^C (Control-C) on the command-line.

Node.js

Now, let's turn to the Node.js version, which looks quite similar, starting with the config file, same name: app.yaml (repo link) but specifying Node 20:

runtime: nodejs20

The Node.js 3rd-party requirements are found in the package.json file (repo link). The Python sample relies on the Flask web framework, and similarly, this Node.js app uses the Express.js framework. The package.json file looks like this:

{
  "name": "helloworld-nodejs",
  "version": "0.0.1",
  "description": "Node.js App Engine sample app",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "author": "@wescpy",
  "license": "Apache-2.0",
  "dependencies": {
    "express": "^4.17.1"
  }
}

Like with Python, call your main application anything you like. Typically with Node.js, they're named app.js, main.js, or what I picked: index.js (repo link). Here are its contents:

const express = require('express');
const app = express();

app.get('/', (req, rsp) => {
  rsp.send('Hello World!');
});

const PORT = process.env.PORT || 8080;
app.listen(PORT, () =>
  console.log(`Listening on port ${PORT}`)
);
module.exports = app;

The app is instantiated after it is required or imported. That's followed by the main (GET) handler returning "Hello World!" regardless of request content. The rest of the app sets up the server on the designated PORT and exports it. Unlike Python which automatically spawns a web server, with Node.js, you have to run your own, hence why this part of the app isn't enclosed in an if block like Python.

Run npm install to install all the required packages in node_modules, specifying the exact versions in package-lock.json. Unlike Flask, Express doesn't log individually-received requests -- developers have to add middleware to see HTTP requests. So if you run npm start to test the app locally, the only output you'll see until you quit the server looks like this:

$ npm start

> helloworld-nodejs@0.0.1 start
> node index.js

Listening on port 8080

As with Python, hit this app with your web browser at http://localhost:8080, and you'll see the same "Hello World!" output in the browser as in the Python screenshot above. Press ^C (Control-C) to quit the Express server.

If you prefer to work with modern ECMAScript modules, a quick require-to-import and similar module export tweaks result in the equivalent index.mjs (repo link) ESM file:

import express from 'express';
const app = express();

app.get('/', (req, rsp) => {
  rsp.send('Hello World!');
});

const PORT = process.env.PORT || 8080;
app.listen(PORT, () =>
  console.log(`Listening on port ${PORT}`)
);
export default app;

Deploying apps to App Engine

Now that you have something working locally, the real exciting next step to take is to run it in the cloud and see how it's accessible globally. Let's start with some GCP setup first.

Google Cloud SDK

To deploy apps to GAE, you need the gcloud command-line tool (CLI). It's part of the Google Cloud SDK (software development kit). If you already have it installed, skip to the next section. If you're new to GCP, follow the instructions to install the SDK and learn a few gcloud commands to get comfortable using it. If you simply want to install the SDK, see these instructions instead. After installation, run gcloud init to initialize it -- you may be prompted to login.

Google Cloud project

A Google Cloud project manages all the resources used for an application, all the platforms and APIs required for your app. Each project can create at most one GAE app. Create a new project or reuse an existing one, and assign a billing account to it if you haven't already.

Every GAE app gets the following domain name for their applications: PROJECT_ID.REG.appspot.com where PROJECT_ID is your project ID (duh), and REG is an abbreviation for the region you choose to run your app from. For your convenience, set your default project with the following command: gcloud config set project PROJECT_ID. If you don't set a default, you must pass in a project ID with the --project-id option each time you deploy your app. Otherwise you'll be prompted for the project ID.

📝 Optional Python-related installs
Python developers have a few additional, optional installations if they're of interest to you.

App Engine SDK (Python 3): If you have an existing Python 2 GAE app using the GAE bundled services and considering to migrate to Python 3, this is for you. The App Engine services SDK (not to be confused with the GCP SDK described above) gives Python 3 apps access to those bundled services bridging Gen2 to Gen1. It can be installed with this command: pip install appengine-python-standard (or pip3).

GCP App Engine "extras": There are a pair of additional, (very) optional GCP components you can add if needed. The app-engine-python component contains the local GAE devserver (not to be confused with the Flask devserver) if you want to simulate bundled services locally. Another one is app-engine-python-extras, which has code for Python 2 apps using built-in libraries. Since 2.x apps can no longer be deployed, it doesn't make sense to install it. Install either or both components with a command line this: gcloud components install app-engine-python-extras app-engine-python

Final setup

Once you've confirmed you've completed these basic tasks, you should be ready to deploy your app:

Install GCP SDK (includes gcloud CLI)
Create new or reuse existing GCP project
Enable billing & assign billing account
Run gcloud init
(optional) Run gcloud config set project PROJECT_ID

Deploy app to App Engine

Once the required steps have been completed, deploy your sample app, whether Python or Node.js. The command to deploy is gcloud app deploy. If you didn't set your project ID with gcloud earlier, pass it in with --project-id PROJECT_ID here. If you do neither, you will be prompted for the project ID.

Every GAE app is hosted in a GCP region. Regardless of which region it is hosted in, your app will be accessible globally. When you deploy the first time, you'll be prompted to set your GAE app's region. You'll only do this once because it's a permanent choice (see sidebar below).

❗ App Engine region cannot be modified!
Every Cloud project can only have one App Engine app, and that app can only ever belong to one region. When assigned, that decision is permanent and cannot be changed, so choose wisely. Rest assured however that regardless of where your app is hosted, it's still reachable globally. Choose a region where you expect most of your users to be. If you insist on another region, you'll have to create another GAE app with another project. One advantage of newer GCP serverless platforms like Cloud Functions (GCF) and Cloud Run (GCR) is that they support more than one function or service and can serve different regions.

❗ App Engine region cannot be modified!

Every Cloud project can only have one App Engine app, and that app can only ever belong to one region. When assigned, that decision is permanent and cannot be changed, so choose wisely. Rest assured however that regardless of where your app is hosted, it's still reachable globally. Choose a region where you expect most of your users to be. If you insist on another region, you'll have to create another GAE app with another project. One advantage of newer GCP serverless platforms like Cloud Functions (GCF) and Cloud Run (GCR) is that they support more than one function or service and can serve different regions.

If you set a default PROJECT_ID, deploy your app with the gcloud command below (whether the Python or Node.js version), but if not, specify the project ID with the --project-id option as discussed earlier.

$ gcloud app deploy
Reauthentication required.
Please enter your password:
You are creating an app for project [PROJECT_ID].
WARNING: Creating an App Engine application for a project is irreversible and the region
cannot be changed. More information about regions is at
<https://cloud.google.com/appengine/docs/locations>.

Please choose the region where you want your App Engine application located:

 [1] asia-east1    (supports standard and flexible)
 [2] asia-east2    (supports standard and flexible and search_api)
 [3] asia-northeast1 (supports standard and flexible and search_api)

. . .

 [21] us-west2      (supports standard and flexible and search_api)
 [22] us-west3      (supports standard and flexible and search_api)
 [23] us-west4      (supports standard and flexible and search_api)
 [24] cancel
Please enter your numeric choice:  19

Creating App Engine application in project [PROJECT_ID] and region [us-east4]....done.

Because your region choice is permanent, you'll never be prompted for it again. The following will be the remaining messages you'll see next for your first and all subsequent deployments:

Services to deploy:

descriptor:                  [/private/tmp/app.yaml]
source:                      [/private/tmp]
target project:              [PROJECT_ID]
target service:              [default]
target version:              [20231205t154433]
target url:                  [https://PROJECT_ID.REG.appspot.com]
target service account:      [PROJECT_ID@appspot.gserviceaccount.com]

Do you want to continue (Y/n)?

Beginning deployment of service [default]...
╔════════════════════════════════════════════════════════════╗
╠═ Uploading 3 files to Google Cloud Storage                ═╣
╚════════════════════════════════════════════════════════════╝
File upload done.
Updating service [default]...done.
Setting traffic split for service [default]...done.
Deployed service [default] to [https://PROJECT_ID.REG.appspot.com]

You can stream logs from the command line by running:
  $ gcloud app logs tail -s default

To view your application in the web browser run:
  $ gcloud app browse

On the first deployment, all three files are new, so that is what the build system uploads. On subsequent deployments, only new and modified files are uploaded. Once deployed, visit the app at: https://PROJECT_ID.REG.appspot.com, a real online address, and you'll see the same "Hello World!" page as before:

[IMAGE] "Hello World!" sample app running globally (PC)

Now that you've successfully deployed a sample Python or Node.js app and have seen it running on Google Cloud, continue to experiment by changing the sample app and redeploying, or uploading one of your "real" apps. Regardless of next steps, you've now learned one place you can run your apps in the cloud, and nowhere in the discussion above did you consider allocating, configuring, or paying for a server.

Summary and next steps

Congratulations on taking your first step in learning about Google's original serverless platform, App Engine. You now know how to deploy simple (and not so simple) web apps to the platform. In addition to web apps, GAE can also be used to host mobile backends. You only need to send HTTP GET and POST requests, and the GAE app needs to have the appropriate handlers for those requests. So overall, is serverless right for you? And what other serverless platforms does GCP offer?

Where should you run your app?

Serverless is the right solution for developers who want their cloud vendor to do most of the heavy-lifting in terms of app-hosting and deployment. It is suitable for apps where the traffic is unpredictable or infrequent (say for student projects, small business websites, mobile backends, etc.), or short-lived apps with extreme traffic, say for a royal wedding as mentioned earlier.

Apps that get steady, continuous traffic, requiring it be available 24x7, is likely best served with VM-based solutions like Google Compute Engine (GCE) or Google Kubernetes Engine (GKE) because the cost of serverless will outgrow its benefits. However, if you're just getting off the ground, serverless helps you get there first, or at least, faster.

Newer serverless platforms > GAE

If serverless sounds right for you, GAE is one option, but GCP has two others: GCF and GCR, both newer than GAE and part of a "Serverless 2.0" generation of products. Recently (Fall 2024), the 2nd-generation of Cloud Functions was rebranded as Cloud Run Functions (GCRF). I'll cover them in follow-up posts in this series, but as briefly mentioned at the top, they're offshoots from GAE's original mission, app-hosting.

All the serverless platforms perform logic-hosting, meaning it's more than just apps now. GCF (and now GCRF) are for hosting functions in the cloud. This is the where you don't have an entire app or don't want/need to worry about full-stack or (LAMP, MEAN, etc.) stacks at all. In these scenarios, you've got smaller snippets of code, microservices or mobile backend functionality.

Similarly, modern software applications are now shipped inside containers. This xx helps isolate dependencies, coordinate versions, and serves the purpose of providing a "shopping bag" for an application and what it depends on. In the past, developers had often had to decide between the flexibility of containers versus the convenience of serverless. This "problem" is directly answered with GCR which runs containers in a serverless fashion.

The newer platforms are generally more flexible than GAE, giving you the ability to have multiple (GCF) functions or (GCR) services vs. one GAE app per project. Both GCF and GCR can be deployed to different regions too, which can be critical for some applications.

GAE > Newer serverless platforms

With all of the above advantages of GCF, GCR, and GCRF, what can GAE still do better? The bundled services are a big part of the picture. Don't most apps need a database, caching server, external task execution, large blob/file storage, etc.? And what if they're (mostly) free and highly-scalable? Yep, that's the promise from the original App Engine team that had come-to-life. With the newer serverless platforms, you'd have to use the standalone GCP services, each of which has their own pricing, or your own best-of-breed options if you prefer, or if GCP doesn't have an exact replacement.

Additionally, GAE infrastructure features an automatic static content service. This free pseudo-CDN (content delivery network) gives you edge-caching without having to set up your own CDN, critical to rendering assets to your users much faster than if served by your application. These are just a few things GAE still does better, so if they're less important for your app(s), you'll likely be better served by the newer serverless platforms.

Billing epilogue

If you want to keep the sample GAE app up and working-as-intended to continue learning and experimenting, great. However, recall it's not a free service, and while you're not likely to incur any charges, the longer you run it, and the more you deploy new versions, this will eventually lead to billable usage. There are several options to minimize getting charged.

One option is to "pause" your app so as to not get billed for inadvertent usage, especially if robots, hackers, or other online scanners discover your app. To do this, disable your app. When you're ready to continue playing with GAE, re-enable it. While your app is disabled and won't incur charges, be aware other resources used in your Cloud project may accrue charges.

Let's say you deployed your app numerous times, with accrued images and other build files exceeding the free tier on GCS or the registries (CR/AR). (In my experience, the registries accrue costs faster than GCS.) These will continue to bill you even with a disabled app, so be sure to tidy both up in addition to disabling your app to avoid (bad) surprises. (Also review the earlier sidebar on costs if you haven't already!)

On the other hand, if you're not going to continue with GAE or this GCP project, delete everything forever to avoid possible billing. To do that, shutdown your project.

Conclusion

If you're a Python, Java, Go, PHP, Ruby, or Node.js developer curious about GAE and made it this far, you now know what the platform is all about and how to deploy a sample app to the cloud.

While new features are primarily going into the newer serverless platforms, GAE is still fulfilling its purpose of providing a serverless app-hosting service with autoscaling properties. GAE apps using bundled services can now migrate from Gen1 to Gen2 with much less friction and upgrade to more recent language versions.

When ready to migrate off the bundled services, developers have additional options of staying on GAE (Gen2), breaking up large apps into multiple microservices for GCF or GCRF, or containerizing their apps for GCR. Furthermore, apps that don't use GAE bundled services can also be migrated to "serverful"/VM-based platforms like GCE or GKE.

If you found an error in this post, bug in the code, or have a topic you want me to cover in the future, drop a note in the comments below or file an issue at the repo. If you have an older GAE app and need advice on possible next steps, whether upgrading from Python 2 to 3, migrating off the bundled services, or shifting to other serverless platforms (GCF/GCRF or GCR), I may be able to help... check out http://appenginemigration.com and submit a request there.

Thanks for checking out my blog... I hope you find this content useful. I enjoy meeting users on the road, so check if I am visiting your community soon... see the travel calendar on my consulting page.

References

Below are various resources related to this post which you may find useful.

Blog post code samples

Google App Engine (GAE) resources

GCP serverless and VM-based compute platforms

Google App Engine (GAE)
Google Cloud Functions (Gen1) and Cloud Run Functions (Gen2) (GCF/GCRF)
Google Cloud Run (GCR)
Google Compute Engine (GCE)
- GCE auto-scaling
- GCE managed instance groups (MIGs)
Google Kubernetes Engine (GKE)
- GKE cluster auto-scaling

GCP serverless content by the author

Pick a GCP serverless platform video
How to design serverless apps video
Exploring serverless with a nebulous app: Deploy the same app to App Engine, Cloud Functions, or Cloud Run blog post, video, code repo, socials

General GAE migration

GAE migration content by the author

Serverless Migration Station (SMS) -- code samples, codelabs, and videos to help GAE users migrate from bundled services
- SMS code samples/codelabs launch post (socials)
- SMS video series launch post (socials)
- SMS video series playlist
- SMS follow-up/summary post (socials)
- SMS code samples GitHub repo (codelabs, videos, "before" & "after" sample apps)
- SMS Shift from GAE to GCF (Gen1) (socials)
- SMS Shift from GAE to GCR with Docker (socials)
- SMS Shift from GAE to GCR without Docker (socials)

Google App Engine (GAE) historical references

GAE 2008 original (Gen1) launch post and video
GAE 2009 ForTran launch (April Fools' Joke) post
GAE 2009 Java launch post
GAE 2009 GAE general availability (GA) announcement
GAE 2012 Go(lang) launch post
GAE 2013 PHP launch post
GAE 2013 original "SharkOn" logo post
GAE 2014 Flexible (Gen1.5) launch post
GAE 2018 Gen2 launch post
GAE 2021 bundled services on Gen2 launch post

DEV Community