Earlier this year, Google announced the End of Support for Java 8 runtime for Google App Engine.
App Engine supports two runtime environments: the first-generation and second-generation environments. While the second generation supports Java 11 and 17, among other languages, the first generation supports only Java 8. This means that all applications on the first generation of App Engine have to migrate before the end of support in January 2024.
At Vanenburg, we have developed a host of Google Cloud Platform (GCP) applications, including several dozen running on App Engine 1.
All these applications need to be migrated out of App Engine this year. In this article, we present possible ways forward. Which option is right for you will depend on your customer or the specific application scenario.
Option 1: Migrate to the second-generation App Engine
Since many of the App Engine bundled services that were used in the first-generation App Engine are still available in the second-generation runtime (such as Datastore API, Memcache API, User Authentication API, Tasks & Scheduler API), migrating to the second-generation App Engine is one of the easiest, fastest and most cost-effective choices. Bear in mind, however, that not all of the services available in the first-generation runtime are available in the second-generation runtime.
If you decide to migrate, the application code will remain largely unchanged.
The application code (compiled using Java 8) has to be compiled in Java 11/17. Fortunately, re-compiling did not break any of the apps that we tested.
Next, some changes are needed in some of the property files.
If the application previously used the Google Search API, you will no longer be able to use this API. Instead, you will have to use an alternative such as ElasticSearch – either as a fully managed ElasticSearch from the GCP marketplace, or with a managed installation of Elasticsearch, for example, in Google Compute Engine. The old Google Search indices will have to be reindexed in ElasticSearch.
The pros and cons of this option are as follows:
Pros:
- Fewer code changes, meaning less time, less expense and lower risks
- Required hosting expertise is similar to that of the first-generation App Engine
- No data migration except for text searches if Google Search API was used
Cons:
- Continue with Google legacy bundles: technical debt
- Vendors continue to be locked in to Google App Engine
- Perpetuate other technical debts: Apart from Google Libraries, we often see old apps using other obsolete technologies, such as AngularJS.
Option 2: Migrate to Cloud Run
With this option, we can pack the existing app as a Docker image that can be deployed to Cloud Run. We can either keep the app in Java 8 itself or move the app to Java 11/17 based on the number of changes in the dependencies used in the application.
The App Engine legacy bundles cannot be used if moving the app to Cloud Run. Therefore, the new Google Cloud Client Libraries should be used.
In this case, the application source code has to be changed for all the Google Libraries used, but the code of the application logic can remain the same.
Pros:
- More code changes (due to migration of the Google legacy Libraries) than Option 1, but the application logic code remains the same and a complete rebuild of the application is not necessary.
- No data migration, as the data can remain in the existing database: Firestore, CloudSQL, BQ, etc.
- Moving to Cloud Run is a good choice because Google views it as an enterprise-ready option for web applications.
Cons:
- Necessary code migration from App Engine legacy API to Google Cloud Client Libraries.
- If the apps are using other obsolete technologies such as AngularJS, then those legacy debts will remain.
- Differences in deployment and infrastructure creation between Cloud Run and App Engine mean your DevOps team must assimilate new knowledge. Docker files have to be built, stored in Artifact Registry and deployed to Cloud Run.
This option involves rebuilding the application in the latest technology stack. A rebuild can be done the traditional way, by manually coding the complete app. This is of course very time-consuming and costly.
An alternative is to rebuild the app with Vanenburg’s Rappit Developer, the high productivity coding product. It generates the source code in the latest technology (Java 17, Angular 15) and it can run as a traditional Spring framework-based application, or it can be Dockerized and run on any container like Google Cloud Run, AWS Fargate or on-premises.
The rebuild option might take more time than the first two options, but has the added advantage of moving out of legacy in less time. Front-loading this work will pay ongoing dividends in the future.
For more on Rappit Developer and Vanenburg services for migration and modernizing your App Engine apps, please contact us.
Google References:
For more information, visit content.rappit.io/google-cloud-platform/
