Running an app migration between different public clouds

These days, I keep pretty busy running cloud migration projects. Now that cloud is well established, some of these migrations are actually from one cloud to another. In one recent project, we needed to migrate apps from AWS and Google Cloud Platform to Azure. For many technologists, there is a tendency to specialize in a single cloud, so it can be a bit of an adjustment to working with multiple major clouds at the same time.

I am usually the one setting up infrastructure and managing the deployment. I use GitHub Actions and Azure Service Principles quite a lot.  With this project, our Kubernetes was on a private Kubernetes service, so we could access it directly using the public internet. This isn’t uncommon, but other aspects of similar migrations can vary.

When deploying with Kubernetes, you should be prepared to work with ingress, service, and deployment YAML files. YAML files allow us to define the parts and definitions of the deployment, the pods, service, and ingress details. The deployment YAML defines what the pods will look like and how many replicas there will be. For example, it can be used to define which pods are the ones doing the back-end service or functionality itself. The service YAML is the one that acts as the load balancer. Ingress is the entry point of the Kubernetes service.

For users experienced with working with templates, figuring out the YAML details is fairly straightforward. One important detail is the vSelector time. This allows you to name the deployment and apply the labels used by the service YAML to determine what pod the service is going to use.

Kubernetes service contains three replicas inside the service. Why do we do that? So that we can make sure the service will load balance if we receive an unexpectedly heavy load like a thousand of HTTP requests. The system will not just throw the thousand requests inside Service A, it will load balance the traffic based on the number of workloads that this service is managing. We can ensure it is reliable and there are no delays or downtime. The important thing to make all of this work is the label.

We should make sure that the label is the same that the service YAML has. You will see a selector under server YAML and you should be sure to set the type as “load balancer.” This is something unique to Azure Kubernetes Service. An additional annotation contains Azure Load Balancer internal, which means it should contain a service IP that is a private IP. If you don’t set this annotation, the service IP will be a publicly accessible IP address. So be sure to prevent accidental access by defining the right annotation!

The pointers I’ve described are useful for keeping things running while the migration happens on the backend. Customer can migrate apps with deployment scripts and YAML files to AKS.