When starting with a legacy, monolithic application, you must find parts thatcan be carved off and moved to separate microservices. Often, a well-structuredmonolithic app will have very natural divisions, and a service class willalready 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 themicroservice.

Separating functionality in a monolithic app

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 staticcode analysis tools to identify the sections.
• Examine your application for logic that you might benefit from differentscaling configuration settings or memory requirements than the rest of yourapplication. This could possibly result in cost savings that might lead tobetter resource utilization.

You might need to refactor your code to remove unnatural dependencies. Werecommend that you perform refactoring within your legacy code and deploy it toproduction 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

Steps for Migrating an App

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

• Leaving the existing code in place and operational in the legacy applicationto facilitate rollback.
• Creating a new code repository, or at least a sub-directory in your existingrepository.
• Copying the classes into the new location.
• Writing a view layer that provides the HTTP API hooks and formats theresponse documents in the correct manner.
• Formulating the new code as a separate application (create anapp.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 fora discussion.
• Altering your existing legacy application to use the new microservicesapplication.
• Deploying the altered legacy application
• Verifying that everything works as expected and that you don't need to rollback to the legacy application.
• Removing any dead code from the legacy application.

Migrating data on a live application

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

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

What's next

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