Migrating a Monolith to Google Kubernetes Engine (GKE) — Migration Process

Get Cooking in Cloud


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…

  1. Migrating a Monolith to GKE: An Overview
  2. Migrating a monolith to GKE: Migration Process (this article)
  3. Migrating a monolith to GKE: Migrate in stages
  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

What you’ll learn

  • Why microservices?
  • Where to start the migration
  • Migration process


  • 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

Why microservices?

In the previous article we laid out a list of reason why moving a monolith to microservices makes sense. Let’s review some of those:

  • Microservices based architecture is beneficial due to its loosely coupled components that can be independently tested and deployed — in theory, the smaller and simpler a component is, the easier it is to maintain and deploy.
  • Each independent service can be implemented in different languages and frameworks so you can use the right tool for the particular job you’re doing.
  • Each component can be managed by a different team reducing dependencies between teams. This clear boundary between services, allows teams to more easily design for failure and it becomes easier to determine what to do if a service is down.

If you don’t design your microservices correctly, you may end up with a distributed monolith, that’s even worse than the monolith you had in the first place.

Where to start?

So, we definitely know it is not going to be simple to migrate a monolithic application to microservices. But to help simplify that process, let’s map the path from a monolithic, on-premises application to an application that’s fully hosted on Google Cloud (built with microservices). Defining the stating and end state helps pave the path for the migration and lay out the migration process.

Starting state

Starting state
  • For most e-commerce platforms, the starting point is a monolithic application on-premises.
  • Your platform probably has load balancers to handle incoming requests from the web.
  • Those requests get routed to your applications servers.
  • These application servers processes the request by utilizing components like Cache, Database, search etc.
  • Additionally, your app servers may send requests to other backend systems.

End state

Now, let’s talk about the end-state and what we are trying to achieve. We definitely want to achieve the same functionality as in the monolith except now instead of running a monolith, we would break that up into individual microservices running in portable, deployable units of code (called containers) using Google Kubernetes Engine (GKE)— a platform to handle scaling, hosting, and deploying containers.

End state or desired state

Migration Process

Now that we have the end state and the start state defined, how do we make the migration happen?

Communication between services on Google Cloud and the monolith on-premises

One of the most important decisions you must make early during such a migration is, how to handle communication between the new microservices hosted on GKE and your legacy systems on-premises. Since we’re migrating in-stages there will be large periods of time where components of your platform will be living in both GKE and on-premises.

Apigee between legacy services on-premises and new microservices in GKE
  • API-based connection: In this type of connection, you use an API management solution such as Apigee as a proxy between the two environments. This gives you precise control over what portions of your legacy systems you expose and how you expose them. It also lets you seamlessly refactor the implementation of an API (moving from a legacy service to a microservice) without impacting the consumers of the API.
Cloud VPN between legacy services on-premises and new microservices in GKE
  • Private network connection: In a solution based on private connectivity, you connect your Google Cloud and on-premises environments using a private network connection. The microservices communicate with your legacy systems over this connection. You can set up IPSec-based VPN tunnels with Cloud VPN. For larger bandwidth, high available and low-latency needs, Cloud Interconnect is a better option.
  • Compared to private connectivity, an API based solution is implemented by the application teams and requires a greater integration with the legacy application, from the get-go. So, it is harder to set up but provides more management options in the long run.
  • On the other hand, a solution based on Cloud VPN or Cloud Interconnect will be implemented by a networking team and initially requires less integration with the legacy application. But, it does not provide any added value in the long term.


The main point — migrating a monolith to microservices on GKE is a complex process that won’t happen overnight — planning out beforehand (how will my services communicate — how will I manage data — what to migrate first), helps to make sure this process goes smoothly.

Migrating a monolith to microservices is a complex process that won’t happen overnight — planning out beforehand (how will my services communicate, how will I manage data, what to migrate first), helps to make sure this process goes smoothly.

If you’re looking to migrate your existing monolithic platform to the cloud, you’ve got a small taste of the migration process. Stay tuned for more articles in the Get Cooking in Cloud series and checkout the references below for more details.

Next steps and references:



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store