Top 5 ways to run your legacy containers on Google Cloud

If your private environment is using Docker and you want to migrate your containers to Google Cloud, this article can help you to choose the right Google Cloud Computing service.

There are many reasons for using public cloud technology like:

increasing scalability,

improving business agility,

reducing cost,

enhancing security.

All of these motivations can turn into big challenges if you choose the wrong cloud computing service.

I have met customers trying to adapt their legacy on a Google Cloud computing service by ignoring the network, security, and devops aspects. This method is not a lift & shift migration. The lift & shift is a journey, it needs a migration plan, cloud adoption, migration path and a clear vision!

I also met customers moving their containerized application to an orchestrator thinking it was a lift & shift migration. They expected minor or no modifications or refactoring needed. This strategy is an improve and move migration and it's also a journey that requires more time.

As a last example, I met a customer wanted to move their containerized application to a serverless, networkless service while maintaining communication with their on-premises environment. A worthless strategy.

When you move to Google Cloud or any other public cloud provider, only your workloads and data will be migrated, your current network, some security patterns and devops practices will remain on your private environments. In Google Cloud, you will need to embrace new best practices and patterns if you want to see your workloads running in production with the initial reasons that motivated you to choose Google Cloud.

In this article, we take an example of a containerized application that needs to be migrated to Google Cloud taking into account many aspects such as network, security, cost and devops challenges.

Google Cloud Compute Services

I explained in a previous post Serverless is not (always) Networkless! that we can represent Google Cloud services in 2 categories:

Services deployed on the Google Cloud network (networkless)

Services deployed in your private network (infrastructure)

The first category is represented by the following computing services:

Cloud functions

Cloud Run

App Engine standard

The second category is represented by the following computing services:

App Engine flexible

Kubernetes Engine

Compute Engine

A container application can be deployed on Cloud Run, App Engine flexible, Kubernetes Engine Standard, Kubernetes Engine Autopilot or Compute Engine.

5) Compute Engine

I would say: don't migrate to Google Cloud if you plan to use Compute Engine to host your containerized application. However, if you still want to host your existing containerized application in Compute Engine, you should be aware of the following constraints:

Compute Engine is not designed to host containers, but you can use Container-Optimized OS, an operating system image that is optimized for running Docker containers.

If you want to scale your application using managed instance group (MIG), each containerized application needs to run on a separate virtual machine. It Could make the operating system overhead a significant part of your cost.

You will have to operate the entire infrastructure on your own: complex security environment, lack of flexibility, upgrade & maintenance, etc.

And other limits

4) App Engine flexible

If you want to host your existing containerized application in App Engine flexible you should be aware of the following constraints:

App Engine flexible is not a serverless service, at least one running container is required

The service requires a private network to create the instances

You can remotely log in to your running instances but they are not accessible through Compute Engine

The most expensive container service because it comes with full PaaS features like firewalls, cron jobs, canary deployment, etc.

Becomes obsolete. Google Cloud doesn't invest much in new features.

3) Kubernetes Engine Standard

If you want to host your existing containerized application in this Kubernetes Engine mode you should be aware of the following constraints:

The service requires a private network to create the nodes

You manage the cluster. So you need a solid knowledge of Kubernetes

Even if no workload is running in the cluster, you will have to pay the GKE control plane fee

2) Kubernetes Engine Autopilot

If you want to host your existing containerized application in this Kubernetes Engine mode you should be aware of the following constraints:

The service requires a private network to create the nodes

Even if no workload is running in the cluster, you will have to pay the GKE control plane fee

Suitable for hosting business applications that you control and maintain. You cannot deploy external tools like Istio (e.g Ingress Gateway)

Nodes are not accessible through Compute Engine

And other limits

1) Cloud Run

If you want to host your existing containerized application in Cloud Run you should be aware of the following constraints:

Your application should start very quickly. Because Cloud Run starts a new container for each new request (in case of cold start) [1]

The service supports only HTTP(s)

Your HTTP(s) requests cannot exceed 60 minutes

Your app does not need to communicate with a service hosted on-premises or in a Google Cloud virtual private cloud (VPC). If you use the Serverless VPC Connector with Cloud Run, you will face network and security challenges that you cannot ignore.

Recommendations

If your existing application is a Web application and does not need to communicate with a private environment, choose Cloud Run.

If your existing application does not need to communicate with a private environment (even if it's possible) and you have multiple teams and projects that need to be separated from each other, App Engine flexible is best suited for this type of organization as it is full PaaS that lets developers focus on what they do best: writing code.

If your existing application needs to communicate with a private environment and

• you need Kubernetes for basic usage, so choose Kubernetes Engine Autopilot.
• you have strong knowledge of Kubernetes, so choose Kubernetes Engine Standard.

Only if your containerized application depends on the Docker Engine, choose Compute Engine.

That's all folks!

Thanks for reading this post :-)

Documentation

[1] https://cloud.google.com/blog/topics/developers-practitioners/3-ways-optimize-cloud-run-response-times