Migrating a Monolith to Google Kubernetes Engine (GKE) — Migrate in stages

Get Cooking in Cloud

Authors: Priyanka Vergadia, Carter Morgan

Introduction

“Get Cooking in Cloud” is a blog and video series to help enterprises and developers build business solutions on Google Cloud. In this third miniseries we are covering Migrating a Monolith to Google Kubernetes Engine (GKE). Migrating a Monolith to microservices can be intimidating. Once you decide to take it on, what are things to consider? Keep reading…

In these articles, we will take you through the entire journey of migrating a monolith to microservices, the migration process, what to migrate first, the different stages of migration and how to deal with data migration. Our inspiration for these articles is this solutions article. We will top it all with a real customer story walking through those steps in a real world application.

Here are all the articles in this miniseries, for you to checkout.

1. Migrating a Monolith to GKE: An overview
2. Migrating a monolith to GKE: Migration process
3. Migrating a monolith to GKE: Migrate in stages (this article)
4. Migrating a monolith to GKE: What to migrate first?
5. Migrating a monolith to GKE: Data migration
6. Migrating a monolith to GKE: Customer story

In this article, we will detail how to migrate a feature in stages. So, read on!

What you’ll learn

• How to prepare your Google Cloud environment for migration
• How to analyze dependencies of services you plan to migrate
• How to migrate features from your legacy environment into the new cloud-based microservice environment

Prerequisites

Before you begin, it’ll be helpful to understand the following:

• Basic concepts and constructs of Google Cloud so you can recognize the names of the products.
• The previous videos in this Get Cooking in Cloud series.

Check out the video

An example use-case

The Ice-cream-theory, is an (imaginary) online ice cream parlor. They are on this journey to migrate their monolith website to microservicesand need guidance in moving their first mircoservice to GKE. They also have the best (imaginary) ice cream on the planet.

Out of all the features they could migrate (check out the next article for more information on how to determine that), they’ve decided to migrate their shopping cart from the legacy monolith app into GKE.

Overall, we recommended that Ice-cream-theory migrate the features of the website one by one to the new environment, creating microservices when required. Those microservices can call back to the legacy system when needed.

Migrating in stages like this has two advantages:

1. Smaller projects are easier to work with, minimizing errors and costly mistakes.
2. And it lets you handle each individual migration without getting overwhelmed.

Let’s see how.

First things, first: Prepare your cloud environment

Mise en place is a French culinary phrase which means “putting in place” or “everything in its place” and refers to the setup required before cooking. For us, that means making sure the environment we’re migrating to is properly set up before migrating features to it. Source: https://pixabay.com/illustrations/cooking-baking-recipe-book-chef-hat-4206076/

Before converting feature into a microservice on GKE, we need a place to put them. For that, we must prepare the Google Cloud environment.

The first thing to set up is a Google Cloud Organization.

Then, we need to ensure only people with the right authorization can access the resources using Google Cloud Policies to control access to the Google Cloud resources.

Next, it’s time to create a plan to Deploy the resources, in a standardized, reproducible way, using infrastructure as code, utilizing tools like Deployment Manager and Terraform.

At this point, we recommend the Ice-cream-theory team to study GKE and it’s features so that they can tweak them for their needs. This will mean changing some of GKE’s defaults and potentially hardening the cluster’s security.

Once GKE is set up, it’s time to build the CI/CD pipeline, using tools like Spinnaker, Jenkins, or Google Cloud products like Cloud Build and Container Registry. Doing this early in the project will avoid problems when they are in production.

Finally, we must decide how miscroservices communicate with each other and whether an API based solution like Apigee or a private connection like cloud interconnect is better for their needs.

Once we’ve figured out the hosting environment, it’s time to start moving features over.

Understanding your feature’s dependencies

Before cooking (migrating features over), it’s important to understand the recipe. In this case, we must be aware of the dependencies of the feature we’re migrating. Source: https://pixabay.com/vectors/recipe-label-icon-symbol-spoon-575434/

The first thing to analyze is the dependencies of the shopping cart feature on the rest of the system. We can do that by reasoning through the steps a user takes when interacting with the website:

1. User makes the ice cream selection and clicks “Add to my shopping cart”. That triggers an API call from the user’s browser to the shopping cart
2. Once the shopping cart receives the call, it checks whether the chosen ice-cream is in stock by making an API call to the inventory system.
3. If the item is in stock, the shopping cart stores the info “Carter has one instance of item strawberry ice-cream in the cart.”
4. Finally, when the user checks out and goes through the payment process, the shopping cart is queried by the payment subsystem to compute the total. And once the payment is complete, the payment subsystem notifies the shopping-cart feature to empty the cart.

So, if we analyze this, at a high level, this shopping cart feature has four dependencies, it is called by the frontend and the payment system, and it queries a database and the inventory system.

Now that we have identified the dependencies, let’s give some thought to the choice of database for this feature. A document database is well-suited for storing shopping carts, since shopping carts can be easily indexed by user IDs and you don’t need the power of a relational database here.

Cloud Firestore is a good fit for this purpose, it’s a managed and serverless NoSQL document database, so let’s consider that for our target architecture.

Migrating your feature to the new environment

Once we migrate over the feature, we’ll be able to enjoy the delicious rewards for our effort. Bon Appétit! Source: https://pixabay.com/vectors/food-plate-fish-vegetable-prawns-576547/

Now comes the biggest piece. migrating the actual shopping cart feature. To simplify the discussion, let’s assume Ice-cream-theory can schedule maintenance down-time for their website.

1. First, they would need to create a new microservice that can call the inventory system and uses Cloud Firestore to implement a shopping-cart API.
2. Then Create a script that extracts shopping carts entries from the legacy shopping-cart system and writes them to Cloud Firestore. This script needs to be written in a way that it can be rerun as many times as needed but only copies the shopping carts that have changed since last time.
3. Then create a script that does the opposite, which is, copies shopping carts from Cloud Firestore back to the legacy subsystem, in case they need to rollback the migration.
4. Then Expose the shopping-cart API with Apigee.
5. They would need to prepare and test the modification to the frontend and payment systems so these systems can call the new shopping-cart system.
6. Again comes the time to run the data-migration script we prepared earlier so all the data is in sync and we did not lose any shopping cart records in the process.
7. At this point they need to put their website in maintenance mode.
8. Re-run the data-migration script.
9. Deploy the tested modifications done to the frontend and the payment system on the legacy production system.

Once done, they are ready to disable maintenance mode in the website, and run traffic through their new microservice!

Conclusion

And with that, the shopping-cart feature of Ice-cream-theory website is now a microservice hosted on Google Cloud. They can continue to dole out tons of delicious ice cream to their happy customers!

Over time, as more of your system becomes microservice based, the entire system becomes more loosely coupled than in a monolithic application, migrating features becomes easier, and those features are easier to modify and deploy.

Migrating in stages has two advantages: smaller projects are easier to work with, minimizing errors and costly mistakes. And it lets you handle each individual migration without getting overwhelmed.

If you are looking to migrate a monolithic application to microservices, you’ve got a small taste of the steps involved through Ice-cream-theory’s use case. Stay tuned for more articles in the Get Cooking in Cloud series and checkout the references below for more details.

Next steps and references:

• Follow this blog series on Google Cloud’s Medium.
• Reference: Monolith to Microservices on GKE solutions.
• Codelab: Migrate a monolith to microservices on GKE
• Follow Get Cooking in Cloud video series and subscribe to Google Cloud’s YouTube channel
• Want more stories? Check my Medium, follow me on twitter.
• Enjoy the ride with us through this miniseries and learn more about more such Google Cloud solutions :)