Migrating a Monolith to Google Kubernetes Engine (GKE) — What to migrate first?
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. 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.
- Migrating a Monolith to GKE: An overview
- Migrating a monolith to GKE: Migration process
- Migrating a monolith to GKE: Migrate in stages
- Migrating a monolith to GKE: What to migrate first? (this article)
- Migrating a monolith to GKE: Data migration
- Migrating a monolith to GKE: Customer story
In this article, we will walk you through how to decide what to migrate first. So, read on!
What you’ll learn
- How to choose a feature to migrate first
- How to factor business processes, teams, operations, and design into your analysis
- 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
How to pick a feature to migrate first?
It is tempting to dive right in and start migrating features as soon as possible. Instead of doing that, taking time to evaluate the following areas of your system will benefit you the most in the long-term:
Start with a business process evaluation. Don’t forget that this will be a learning experience and there will be mistakes to learn from. So for that reason, the initial efforts should not involve business critical systems but they should still represent a significant use case to the team to learn from.
From a design and development point of view, you want to pick features that have the least number of dependencies and which are easiest to refactor if necessary. Also consider the cost & complexity of developing or refactoring as necessary.
From operations point of view, think about features that can afford the down-time of the cut-over window. If you need to minimize downtime, migrating features that require high availability can mean extra work.
And finally, choose teams that have well defined processes to lead the initial efforts. Because you want them to lead the way for this migration journey and understand that they will encounter new challenges for which they must find solutions.
The ideal feature for a first-migration requires little refactoring, is stateless, has no external data requirements, and has few or no dependencies.
Taking all of these factors into account, this recipe calls for ‘Divide & Conquer’ approach where we find a “challenging but meaningful” feature to migrate first. The feature must be meaningful and challenging enough to be a useful way of testing and refining our assumptions about the migration.
Let’s see an example to make this clear.
An example migration plan
Consider our friends at Ice-cream-theory and their migration (from the last article).
Because they are thinking about a full migration of their website to micro-services, a good migration order for them could be to migrate the frontend first; then think about stateless features; next could be features with independent datasets, such as a service that lists their brick-and-mortar stores; and then finally come to features with shared datasets like the business logic of the platform itself.
The platform frontend, followed by any stateless features, like a currency-conversion system, go first because they usually have few dependents and often require limited refactoring because in the “Initial Migration” recipe, the backend API is still being served from the legacy datacenter or runtime hosted on-premises or on another cloud.
After stateless features, components whose datasets have no dependencies on other datasets, such as services to list the brick and mortar stores, are the next to migrate. These are easier to extract and move to a modern storage system like Cloud Storage or Cloud Firestore for managed data storage, Cloud SQL for relational data, or Cloud Firestore for document based noSQL data.
Finally features with shared datasets, like the business logic of the e-commerce platform, are the hardest to migrate because of the requirements for consistency, distribution, access and latency across legacy and new services.
Since data migration is not as simple, we are dedicating the entire next article to it, stay tuned.
Conclusion
When you plan your migration, it’s tempting to start with features that are trivial to migrate. This might be a quick win, but might not benefit your project the most over the long-term. Instead of diving straight into the migration, you should spend time evaluating each feature and create a plan for their migration.
Taking time to evaluate your features business processes, teams, design & development, and operations *before* you begin migrating them, will help your migration process, immensely.
If you are looking to migrate a monolithic application to microservices, then you’ve got a recipe to decide which features to migrate first. 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 :)
