Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://cloud.google.com/appengine/docs/legacy/standard/python/microservice-migration below:

Migrating to Microservices from a Monolithic App | App Engine standard environment for Python 2

Stay organized with collections Save and categorize content based on your preferences.

When starting with a legacy, monolithic application, you must find parts that can be carved off and moved to separate microservices. Often, a well-structured monolithic app will have very natural divisions, and a service class will already function as an interface to a layer of data storage and business logic. Such classes are the ideal place to connect the client calls to the microservice.

You could take a couple approaches for how you separate your app:

• Look for business logic in your application that can be separated.
• Find code that is naturally isolated, such as by using static code analysis tools to identify the sections.
• Examine your application for logic that you might benefit from different scaling configuration settings or memory requirements than the rest of your application. This could possibly result in cost savings that might lead to better resource utilization.

You might need to refactor your code to remove unnatural dependencies. We recommend that you perform refactoring within your legacy code and deploy it to production before attempting to separate the app into separate services.

Common areas for microservices include the following:

• User or account information
• Authorization and session management
• Preferences or configuration settings
• Notifications and communications services
• Photos and media, especially metadata
• Task queue workers

After a set of classes has been identified as a candidate to become a microservice, the next steps include:

• Leaving the existing code in place and operational in the legacy application to facilitate rollback.
• Creating a new code repository, or at least a sub-directory in your existing repository.
• Copying the classes into the new location.
• Writing a view layer that provides the HTTP API hooks and formats the response documents in the correct manner.
• Formulating the new code as a separate application (create an app.yaml).
• Deploying your new microservice as a service or separate project.
• Testing the code to ensure that it is functioning correctly.
• Migrating the data from the legacy app to the new microservice. See below for a discussion.
• Altering your existing legacy application to use the new microservices application.
• Deploying the altered legacy application
• Verifying that everything works as expected and that you don't need to roll back to the legacy application.
• Removing any dead code from the legacy application.

Data migration on a live application can be tricky and highly dependent on your situation. Often, to facilitate roll-forward and rollback, you will need to write code that populates both the old and new Cloud Datastore entities, possibly by using a temporary API on the microservice, and then write code that migrates the existing set of data, for example as a MapReduce. This process will usually involve some amount of temporary code and redundant data. Depending on the specifics of your situation, you may also need to execute a catch-up data migration after you release. Be careful not to overwrite newer data with older data.

While this seems like a lot of work, it's a common occurrence and is important to allow for rolling forward and rolling back in the event that the cutover to the new microservice does not succeed. You can remove your temporary code and delete the data from the old storage location only after you have verified that everything is migrated correctly and everything is operating as expected. Be sure to make backups along the way.

• Get an overview of microservice architecture on App Engine.
• Understand how to create and name dev, test, qa, staging, and production environments with microservices in App Engine.
• Learn the best practices for designing APIs to communicate between microservices.
• Learn the best practices for microservice performance.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-07 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["Identifying well-structured service classes within a monolithic application is the ideal starting point for transitioning to microservices, as they often naturally interface with data storage and business logic."],["Separating a monolithic application into microservices involves analyzing business logic, isolating code, and considering scaling needs, with refactoring recommended before the separation."],["Common areas suitable for microservices include user information, authorization, settings, notifications, media, and task queues."],["Migrating to a microservice involves creating a new repository, copying classes, building an HTTP API layer, deploying as a separate app, testing, migrating data, and updating the legacy app."],["Data migration in live applications often requires populating both old and new storage systems to ensure seamless roll-forward and rollback, involving temporary code and redundant data."]]],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4