Migrating a Monolith to Google Kubernetes Engine — An Overview
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.
- Migrating a Monolith to GKE: An Overview (this article)
- Migrating a monolith to GKE: Migration Process
- Migrating a monolith to GKE: Migrate in stages
- Migrating a monolith to GKE: What to migrate first?
- Migrating a monolith to GKE: Data migration
- Migrating a monolith to GKE: Customer Story
In this first article, we will introduce you to the concept of Monoliths and Microservices.. So, read on!
What you’ll learn
- What is a monolith
- What is a microservice
- Why move to microservice based architecture
- Three main migration patterns
Prerequisites
- Basic concepts and constructs of Google Cloud so you can recognize the names of the products.
- Check out the introduction of Get Cooking in Cloud series.
Check out the video
What is a monolith?
A monolith is an application built as a single deployable unit. Examples include a single Java EE application or a single .NET Web Application. A monolithic application is often associated with a database and a client-side user interface.
What is a microservice?
A single service that’s built to accommodate an application feature. In the microservices pattern, the application is the aggregate of multiple services, each having a specific goal. For example, you might have a service that handles the shopping cart for your customers, another one for handling the payment service, and another one for interfacing with a backend application for stock. Those microservices should be loosely coupled and they should interface with each other through well-defined APIs. They can be written in different languages and frameworks, and they can have different life cycles.
Why move to microservice based architecture?
Imagine you are an IT professional in charge of a complex website you need to modernize and it is designed as a monolith and now it is time to move to the cloud. Maybe the way things have been done is mostly working for you: but when it comes time to upgrade a service, or add a new feature — you start running into problems: like feature roll outs taking forever because your monolithic app can only be deployed once a quarter. Not just this, here are some of the reasons for move to microservices:
- The microservices can be independently tested and deployed. The smaller the unit of deployment, the easier the deployment.
- They can be implemented in different languages and frameworks. For each microservice, you’re free to choose the best technology for its particular use case.
- They can be managed by different teams. The boundary between microservices makes it easier to dedicate a team to one or several microservices.
- By moving to microservices, you loosen the dependencies between the teams. Each team has to care only about the APIs of the microservices they are dependent on. The team doesn’t need to think about how those microservices are implemented, about their release cycles, and so on.
- You can more easily design for failure. By having clear boundaries between services, it’s easier to determine what to do if a service is down.
How to move to microservice based architecture?
Without a recipe, it can be hard to know exactly how to transition your application to microservices, in a way that minimizes risk, downtime, customer dissatisfaction, and money lost. Modernizing your platform by moving to the cloud and by switching to microservices involves learning new tools, new ways of working. All of that can seem overwhelming. But those fears shouldn’t stop you from reaping the benefits of a microservice-based architecture.
Migration Patterns
If you were to just migrate everything at once — there’d be a lot of risks involved. But if you were to migrate feature by feature you can avoid a large amount of risk involved. There are three main patterns for this type of migration to the cloud:
- Lift and shift: It means you are really just moving the same workload or application from one location to another. No change, no edits, just move as is.
- Improve and move: This is the pattern where you repurpose an existing solution for cloud. Example, making changes like synchronous to asynchronous flows with event processing, or even moving from monolith to microserverices in some cases.
- Rip and replace: This involves complete redesign of the app using cloud-native components. Example: Using managed and serverless services.
We’re going to use a specific flavor of the rip and replace pattern, where the pattern is applied incrementally to each feature of the application, rather than to the application as a whole.
Over the next few articles, we’ll use e-commerce websites as an example because many of these are built with monolithic proprietary tools, so they are really good candidates for this migration. But even if you don’t have an e-commerce site, you can apply the principles that we’ll cover here to a wide range of workloads.
In addition to this migration pattern, we’ll show you two hybrid patterns. During the migration itself, the application has a hybrid architecture where some features are in the cloud and some are still on-premises. After the migration is finished, the complete application is hosted in the cloud, but it still interacts with backend services that remain on-premises.
Conclusion
If you’re looking to migrate your existing monolithic platform to the cloud, you’ve gotten a small taste of what’s in store for the rest of this series. Stay tuned more articles in the Get Cooking in Cloud series.
Next steps and references:
- Follow this blog series on Google Cloud Platform 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 platform 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 :)
