TL;DR:
Google App Engine (GAE) is not shutting down. Instead, the 1st-generation (and older 2nd-generation) runtimes will reach "end-of-support" at the end of Jan 2024.
Affected GAE runtimes
While Python 2 users are the focus of this post, all of the following runtimes are affected:
- Python 2.7
- Python 2.5 was already deprecated in 2013 and shutdown in 2017
- Python 3.7
- Java 8
- PHP 5 & 7
- Go 1.11-1.18
- Ruby 2
- Node.js 10-16
Overall, this deprecation significantly affects developers belonging to one of these groups:
| Scenario | How affected | Action |
|---|---|---|
| You regularly deploy affected apps to App Engine | Cannot deploy apps starting Feb 2024 | Immediately: a) upgrade to currently-supported runtime to stay on GAE, b) stay on 2.x but shift workload elsewhere, c) freeze your app, or d) ask for exception (see "Quick summary" below) |
| You have affected apps but do NOT regularly deploy them to App Engine | Apps continue to run but clock ticking | Start exploring one of the options above |
Quick summary of options
- Upgrade to Python 3.8+ (or other supported runtime: Java 11+, PHP 8+, Go 1.19+, Ruby 3+, Node 18+) to stay on GAE
- Stay on Python 2 (or other affected runtime) but shift workload to another GCP serverless platform: Cloud Run^
- Stay on Python 2 but shift workload to GCP VM-based solutions like Kubernetes/GKE or Compute Engine^
- Stay on Python 2 but shift workload off GCP^
- Stay on Python 2 but freeze your app, meaning no app updates or new deployments (leave it as-is)
- Ask for an exception
^ — requires migrating away from GAE bundled services
Prologue
Happy holidays, and welcome to the blog focused on using Google APIs from Python and sometimes Node.js. The previous post series focused on credentials types, for example, OAuth client IDs, primarily used for Google Workspace (GWS) APIs, and API keys, primarily used for Google Maps APIs. API keys are used by many other Google API families, such as YouTube, Google Cloud (GCP), and also GWS. While the next series finally tackles the 3rd credential type supported by Google APIs, service accounts, we're taking a temporary detour to discuss another Google developer product: Google App Engine.
Introduction
We'll do a deeper dive introducing App Engine in an upcoming post but wanted to focus just on a product deprecation today, a big one. For now, you only need to know that App Engine lets developers host applications in the cloud without having to be concerned with its infrastructure, or "what it runs on" basically. You write a web app (or mobile backend), and without thinking about virtual machines (VMs) or Kubernetes, upload that app to GAE, and it runs your app in the cloud, autoscaling if necessary. The product has a major update coming at the end of Jan 2024.
Google originally launched the platform back in 2008 (video)—its first cloud product actually—giving rise to serverless computing and the cloud computing Platform-as-a-Service (PaaS) service level. It originally launched supporting Python 2.5, later upgrading to 2.7, and also added language support for Java, Go, and PHP. A decade later, the 2nd-generation platform launched, adding support for Python 3+, Java 11+, Go 1.12+, PHP 7+, and adding new support for Ruby and Node.js.
All older apps, however, remained on the 1st-generation platform. Even with the sunset of Python 2, Java 8, PHP 5, and Go 1.11, by their respective communities, the Google Cloud team assured users by expressing continued long-term support of these legacy runtimes, including maintaining the Python 2 runtime until vendor support was no longer available. That time is now, so Google is finally deprecating its support as well.
Python 2.7 deprecation notice
All of the Python 2 App Engine documentation today displays a somewhat concerning but necessary notice at the top:
It reads as:
Note: Python 2.7 will reach the end of support on January 31, 2024. After this date, your existing Python 2.7 applications will continue to run and receive traffic. However, you cannot deploy new or update existing applications that use runtimes after their end of support date. We recommend that you migrate to the latest supported version of Python.
There's still time for you to take action. Let's discuss.
What does "end of support" mean?
The deprecation notice doesn't spill all the beans, but here are the key takeaways about what "end of support" means:
- Users can no longer deploy new apps or new versions of existing apps using affected runtimes.
- Already-deployed apps will stay up-and-running and receiving traffic.
- If your app is "mission-critical," you may be able to get an exception
- Per the documentation: Google will no longer apply security updates, and apps will not be eligible for technical support.
So what does this mean for developers, or more importantly, what do you need to know?
What you need to know
| Is this you? | Action Item |
|---|---|
| Your app uses an "end of support" runtime like Python 2, but you don't (or can't) update or (re)deploy it. | Your app continues to run beyond the "end of support" date, but you can no longer update it at all. It will run as-is until the decommission date (none published yet); start looking at your options (migrate, move, etc.) while you have time. |
| Your app uses an "end of support" runtime, and you update it "regularly." | You are directly impacted because after the "end of support" date, you will no longer be able to deploy your app. Take action now. Your options depend on whether you want to stay on App Engine or move elsewhere. Much more in the upcoming section on Migration Options. |
| You're a consultant that regularly creates new App Engine apps for clients but they use an "end of support" runtime. | Similar to the above, you're impacted directly and will no longer be able to deploy new apps using affected runtimes. Craft all subsequent projects using a supported runtime. |
| Your "end of support" runtime app is "mission-critical." Can I get an exception? | This may be possible. According to the documentation: In certain cases, Google may permit your Organization to re-enable deployments.... Deployments for legacy runtimes can be re-enabled using an organization policy. |
| I don't have a Python 2 app... my GAE apps are written in Java, PHP, Go, Ruby, or Node.js/JavaScript. Am I affected? | The "end of support" date affects more than just Python 2 users. All 1st-generation and older 2nd-generation runtimes are affected, meaning you should also upgrade those apps to a GAE-supported runtime or consider moving your app elsewhere. |
| I have an app using an "end of support" runtime and am concerned about this deprecation but don't know what to do. | Contact your original developer(s) or consultant(s) on upgrading or migrating. If you cannot find them, have exhausted all your options, or don't know what else to do, complete the form at https://appenginemigrations.com to see if I can help and have availability. |
Migration options
If you don't take any action now, your app using an "end of support" runtime like Python 2 will continue to run on GAE as-is, even after the coming "end of support" date. At that time, there can be no new deployments and no tech support. Now is a great time to take some action to either upgrade to a supported runtime or move to another solution that still supports specific languages and versions of affected runtimes.
Bundled services considerations
Early users are familiar with the set of original "App Engine APIs" like Datastore, Memcache, Task Queue, Blobstore, etc., now collectively referred to as GAE "bundled services" that help power your apps. Bundled services are only available in runtimes that were part of GAE's 1st-generation platform (Python 2, Java 8, Go 1.11 & older, PHP 5). Runtimes that never had a 1st-generation version (Ruby, Node.js) do not (and will not) have (or get) bundled services.
When the GAE 2nd-generation service launched in 2018, the team omitted these bundled services as they tied apps to the platform, meaning they could only run on GAE. By removing the bundled services, developers could now choose the best-of-breed alternatives so their apps are portable to other GCP or even non-GCP hosting platforms. The only challenge was that existing developers were required to migrate away from those bundled services in order for their app to run on newer runtimes only supported by the 2nd-generation platform, e.g., Python 3, Java 11, Go 1.12+, PHP 7.
Unfortunately, it was mutually exclusive to do so, meaning while you could upgrade language releases, say to Python 3, that migration is paired with a possibly greater migration away from the bundled services, making the entire move (to the 2nd-generation platform) a showstopper for many users. For this reason, the App Engine team added most of the bundled services in 2021 to the 2nd-generation runtimes for languages that had a 1st-generation runtime (Python, Java, Go, PHP).
The purpose of the entire release was to help with users upgrade language releases to Python 3 (or Java 11+, Go 1.12+, PHP 8) and finally being able to run on the 2nd-generation platform. Once apps were ported to updated language versions, developers could then migrate off the bundled services on their own terms and timelines, splitting up two potentially challenging migrations. All this said, what are the available options for "end of support" runtime developers now?
Options for "end of support" runtime apps
If you've got a Python 2 (or affected) app, here are your choices (and any additional caveats/notes):
- Stay on 2.x but freeze your app: no app updates or new deployments (good until decommission)
- Bundled services users can port to Python 3.8+ (or Java 11+, PHP 8+, Go 1.19+) to stay on GAE
- Ruby 2 & Node 10-16 users must upgrade to Ruby 3+ & Node 18+ to remain on GAE (no bundled services)
- Stay on 2.x but shift workload to another GCP serverless platform: Cloud Run (GCR)
- Requires migrating away from GAE bundled services
- How to migrate a sample app from GAE to GCR (Docker use required)
- Solution only works as long as Python 2 Docker base images exist
- Cloud Functions (GCF) does not support Python 2
- Stay on 2.x but shift workload to GCP VM-based solution like Kubernetes/GKE or Compute Engine
- Requires migrating away from GAE bundled services
- Stay on 2.x but shift workload to non-GCP compute platform
- Requires migrating away from GAE bundled services
- Ask for an exception (per entry in above chart)
Migrating to Cloud Run
For those wishing to remain on Python 2, Cloud Run is an option as it there's still a Python 2 Docker base image. The only real challenge is to migrate off the GAE bundled services. If you're willing to do so, then it's certainly a good option. I created some content if you want to experiment and migrate a sample app from GAE to GCR with Docker.
Furthermore, to help developers better understand the GCP serverless platforms (App Engine, Cloud Functions, Cloud Run), learn the differences between them, and see how to shift apps between them, e.g., from GAE to GCF or GCR, check out this sample application I created that can be deployed to all three platforms with no code changes. There's also a corresponding video that walks through deploying Node.js, Python 2, and Python 3 versions of that app to all platforms.
Migrating off GAE bundled services
Using the bundled services is certainly convenient and familiar to long-time GAE users, but recognize they are proprietary Google services, restricting apps from leaving the GAE platform. Developers who want more flexibility, including being able to move their apps off of GAE, should migrate away from the GAE bundled services. The good news is that many of them have matured enough to now be available as "new" standalone GCP services.
I created a set of hands-on tutorials ("codelabs") as well as overview videos covering migration away from the key bundled services including "before" and "after" sample apps so you can familiarize yourself with the migrations.
Summary
The "end of support" date is coming soon, and it affects developers who update their apps regularly: you will no longer be able to do so in Feb 2024. Python 2 (and other affected runtime) apps will remain up and serving requests after that date, giving developers time to work on upgrading to a supported GAE runtime. Timing is of the essence as this date marks a line in the sand for you to work on a migration solution that can be slowly eased-in to take the place of its predecessor. Your old app can stay up and serving your users while you craft a replacement. When ready, launch the replacement service gradually, taking some traffic, working out bugs, until you can completely drop the old app.
I recommend app owners start that project or contact their original developer(s) as soon as possible. If all else fails, I may be available; contact me at https://appenginemigrations.com. Also review the story of one developer who successfully completed this upgrade with minimal downtime.
What's Next?
Now that you know about this GAE deprecation, you may be wondering what's the big deal with App Engine anyway? What is its history, and how you can use today's GAE platform? That will be covered in the post in this series, so stay tuned. This is the first post covering Google Cloud (GCP). Expect future GCP content to cover topics like GAE bundled services, GAE migration, other serverless platforms like GCF or GCR, or other GCP compute products or its numerous APIs.
References
- Google App Engine product page
- All App Engine documentation
- Python 2 App Engine documentation
- GAE runtime lifecycle
- GAE support schedule
- Python 2 GAE migration home page
- Migrating away from GAE bundled services
- Python 2 GAE migration GitHub repo (codelabs, videos, "before" & "after" sample apps)
- Python 2 GAE migration codelabs
- Python 2 GAE migration videos
- Content on migrating from GAE to GCR (with Docker)
- Python support on GCP
WESLEY CHUN, MSCS, is a Google Developer Expert (GDE) in Google Cloud (GCP) & Google Workspace (GWS), author of Prentice Hall's bestselling "Core Python" series, co-author of "Python Web Development with Django", and has written for Linux Journal & CNET. He runs CyberWeb specializing in GCP & GWS APIs and serverless platforms, Python & App Engine migrations, and Python training & engineering. Wesley was one of the original Yahoo!Mail engineers and spent 13+ years on various Google product teams, speaking on behalf of their APIs, producing sample apps, codelabs, and videos for serverless migration and GWS developers. He holds degrees in Computer Science, Mathematics, and Music from the University of California, is a Fellow of the Python Software Foundation, and loves to travel to meet developers worldwide at conferences, user group events, and universities. Follow he/him @wescpy & his technical blog. Find this content useful? Contact CyberWeb or buy him a coffee (or tea)!
Top comments (0)