Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud
Introduction and background
The Serverless Migration Station collection is aimed toward serving to builders modernize their apps operating one in all Google Cloud’s serverless platforms. The previous (Migration Module 18) video demonstrates the right way to add use of App Engine’s Process Queue pull duties service to a Python 2 App Engine pattern app. At the moment’s Module 19 video picks up from the place that leaves off, migrating that pull activity utilization to Cloud Pub/Sub.
Shifting away from proprietary App Engine companies like Process Queue makes apps extra transportable, giving them sufficient flexibility to:
Understanding the migrations
Module 19 consists of implementing three completely different migrations on the Module 18 pattern app:
- Migrate from App Engine NDB to Cloud NDB
- Migrate from App Engine Process Queue pull duties to Cloud Pub/Sub
- Migrate from Python 2 to Python (2 and) 3
The NDB to Cloud NDB migration is an identical to the Module 2 migration content material, so it is not lined in-depth in Module 19. The unique app was designed to be Python 2 and three appropriate, so there is no work there both. Module 19 boils down to 3 key updates:
- Setup: Allow APIs and create Pub/Sub Subject & Subscription
- How work is created: Publish Pub/Sub messages as an alternative of including pull duties
- How work is processed: Pull messages as an alternative of leasing duties
Apart from these bodily modifications, a key hurdle to beat is knowing the variations in terminology between pull duties and Pub/Sub. The next chart makes an attempt to demystify this so builders can extra simply grasp how they differ:
 |
| Terminology variations between App Engine pull duties and Cloud Pub/Sub |
Reflecting the chart, these variations could be summarized like this:
- With Pull Queues, work is created in pull queues whereas work is shipped to Pub/Sub matters
- Process Queue pull duties are known as messages in Pub/Sub
- With Process Queues, employees entry pull duties; with Pub/Sub, subscribers obtain messages
- Leasing a pull activity is similar as pulling a message from a Pub/Sub subject by way of a subscription
- Deleting a activity from a pull queue whenever you’re carried out is analogous to efficiently acknowledging a Pub/Sub message
The video walks builders by way of the terminology in addition to the code modifications described above. Beneath is pseudocode implementing the important thing modifications to the principle software (new or up to date strains of code bolded):
 |
| Migration from App Engine Process Queue pull duties to Cloud Pub/Sub |
Observe how a lot of the code, particularly app operations and information fashions are left comparatively unchanged. The one seen modifications are switching from App Engine NDB and Process Queue to Cloud NDB and Pub/Sub. Full variations of the app earlier than and after making the modifications could be discovered within the Module 18 and Module 19 repo folders, respectively. Along with the video, be sure you try the Module 19 codelab which leads you step-by-step by way of the migrations mentioned.
Wrap-up
Module 19 encompasses a migration of App Engine pull duties to Cloud Pub/Sub, however builders ought to observe that Pub/Sub itself is just not primarily based on pull duties. It’s a fully-featured asynchronous, scalable messaging service that has many extra options than the pull performance offered by Process Queue. For instance, Pub/Sub has different options like streaming to BigQuery and push performance. Pub/Sub push operates in a different way than Process Queue push duties, therefore why we suggest push duties be migrated to Cloud Duties as an alternative (see Module 8). For extra info on all of its options, see the Pub/Sub documentation. As a result of Cloud Duties does not assist pull performance, we flip to Pub/Sub as an alternative for pull activity customers.
Whereas we suggest customers transfer to the most recent choices from Google Cloud, neither of these migrations are required, and do you have to decide to take action, can do them by yourself timeline. In Fall 2021, the App Engine workforce prolonged assist of lots of the bundled companies to 2nd era runtimes (which have a 1st era runtime), which means you do not have emigrate to standalone Cloud companies earlier than porting your app to Python 3. You may proceed utilizing Process Queue in Python 3 as long as you retrofit your code to entry bundled companies from next-generation runtimes.
For those who’re utilizing different App Engine legacy companies be sure you try the opposite Migration Modules on this collection. All Serverless Migration Station content material (codelabs, movies, supply code [when available]) could be accessed at its open supply repo. Whereas our content material initially focuses on Python customers, the Cloud workforce is engaged on masking different language runtimes, so keep tuned. For added video content material, try our broader Serverless Expeditions collection.
