Kubernetes: How to migrate the application to a different infrastructure

share this on:

  

See how to migrate the application to a different infrastructure, moving it from on-prem to the cloud, and how to achieve declarative management, manual and automatic scaling of services, health monitoring and self-healing and automated rollouts and rollbacks.


[Video Transcript] 

I will get back to this database part because it's interesting, and because it relates to one specific component that I mentioned earlier: the state part of the state persistence part. Let's take this application and move it somewhere else, and just to prove to you that I am actually destroying this and moving to another place. This is on premises. This is a 10, that 10 IP subnet and I will move to the cloud.

I have a very similar cluster, depending on the cloud. This is just a VSP, what we could platform and different VMs, different base images because the cloud, the image are different from the ones I have on premises, but our application will not care. 

Let's take the application and move it to the cloud. First of all, I will destroy it in my original data center. The name space, everything will go away.

Notice that the web page has stopped responding. 

Let's start everything up in the cloud.

The clouds, same comment, same Yamen manifest, even though the infrastructure is quite different. We don't care. We only care about one important change: The IP addresses have changed. Of course,  we moved the application. We have different IP addresses, but this is where the magic of DNS comes in, just as clouds here, and this points to a different IP address, the one allocated to me by the cloud provider, and we are once again, you know, an application. I will do the same here for the results. And once you start voting, you will begin to see this. 

How long did it take me to move the application?

15 seconds, 30? Okay. Again, it depends on many things. And I will admit that I have simplified some things here, but you have to admit that simply taking the application and redeploying it somewhere else can be very, very easy, and everything that we have discussed so far, scaling, self-healing capabilities, everything is still the same.

It doesn't matter if you're using your own Kubernetes cluster, like ID, it doesn't matter if you're using one of the managed Kubernetes offerings such as the GKE or EKS or HKS, things work the same way. 

But I will admit that I have simplified things a little bit. When I moved their application, there was one thing that I didn't care about.

I didn't care about the state. When I moved the application, the votes that were originally cast were lost, but in this case it was fine for me. I didn't care about the state, but what if you actually wanted to move the scale? The state, sorry, the move, the state of the application as well. 

Well, you just need to back up the restore database and this is what brings us back to the previous question about databases, and this is why using Kubernetes

Does that mean that you stop using the database specific utilities. One more thing you need to do if you want to preserve the state in this case is back up the database task for the backup to the cloud, restore the backup inside the new database instance that you have started in the cloud.

Something that we have been doing for many years now, backing up and restoring the database is definitely not something new. So some of the skills that you are familiar with do not go away, and I do believe that this should answer the question about databases. 

Some of the management is done the same way, and you do have some additional tools, some additional capabilities that come into play, if you're on that database as an application in Kubernetes. 

This concludes our demo. What have you seen so far? What are the Kubernetes? What it can do, how we can run an application Kubernetes? How can we scale that application? How can we take advantage of Kubernetes, its capabilities to always give you the application running, even if one component develops a problem?

And then we have seen how easy it is to take the application and move it from on premises to the cloud. And of course, it's just as easy to move it back again. 

Want to learn more? See our Kubernetes courses!

 

share this on: