Mike Ensor – Google Demo: Automating Modernization with Anthos Migrate

Hi, my name is Mike Ensor and I'm with Google, and if you did not have an opportunity to see our technical explanation, please refer back to the presentation on our anthers migrate. What I'm going to do now is I'm going to demonstrate the principles and values that we had discussed in that presentation. I'm going to go and perform those here in a demo.

So to start off with, I want to show a legacy application. And I made something that looked like a late 90s Web page with some good blinking text in those types of things. I even have a widgets page and I want to explain why I have these.

So the first page, we're going to basically take the migration tool and we're going to migrate this application all on its own. This second page here is a widget based page and notice it's under construction. So a part of our process is we're going to override that with a microcircuits that's going to provide that functionality.

So just as a brief reminder, this is what the application process looks at or the automation process looks like. We're starting doing some configuration set up or running through the actual migration. We're creating two repositories, one for the microcircuits and one for the original monolithic application will create some magic with some engross controllers and we'll do some deployment functionality.

So let me explain what our application or what our repository is look like, we have a series of we have a the existing model. This is pretending like this is going away and we have no visibility into source. And so it's just the monolith application.

We have the automation workflow, which is what we're kicking off. First I go and kick that off and come back and describe the rest of this functionality. So I haven't set up such that all we need to do is either make any changes to the application and make the pusher's, or you can just run the pipeline manually.

The pipeline that gets run. It's got three major stages and three different jobs. We're going to first install and set up the antennas for migrate that will be followed up by creating the actual sources.

And so these sources are things like VMware. It could be us or as your machines, it could be GCE instances. There's various different sources that we can then pull information from.

This is the configuration for that. Then we the last thing we do is the output of that actually produces a series of YAML files that are used for configuration. So this whole first stage here is really setting up what is being migrated and what are the plans to make that migration happen while that's being kicked off, I'm going to show the repository, the layout of the repositories.

In here, I want to point out that gitlab, we are leveraging the concept of template applications, what allows me to do is I can create templates of what my future applications will look like. And so when I create a new repository, I can then refer to these templates. And so I have a monolithic application and I have a modern application.

I also have a hidden private where I am actually able to encapsulate the CD pipelines and so I can create a don't repeat yourself or dry CD pipeline inheritance model. Let's go back and see where we're at in the build. Looks like we have a little bit of time here, so we will let this migration get kicked off and get started and I'm going to just sit for a moment.

All right, so welcome back here. We're at the migration point, the output of the pipeline that we've been working on that that generates that configuration is going to spawn two different repositories. Want to point out we have a subdirectory or a subgroup called migrated applications.

This is where the pipeline is going to generate those two repositories. Let's take a look at what's going on. All right, and so the output of our hour log that we're seeing here is we're creating a new project.

In this case, we're creating the project to hold the contents of the output from Anthos migrate. This is the configuration for setting up an actual migration itself, the actual bike copy at this point. So it takes just a moment to generate this and at the same time are going to be creating a second repository as well, that a second repository is the site, the companion application that's going to be in the microspheres that works with this.

All right, and that job succeeded, so let's take a look at what was created, some just refresh my sub-group here. And we'll see that we have two new applications that are tuner repositories that exist. Again, these are under the migrated apps.

We're going to start by taking a look at the migration itself. And we're in a state where we have done nothing so on the on the master branch or the primary branch, we have no no changes to be made at this point. It's just a base.

So I want to point out the sequence in the area that we're going to perform next is actually making this migration happen, which is in the phase two. So the way we do this is we're using feature branches or special branches to contain the changes that we want. This allows us to have an opportunity to say, are things appropriate?

Are they are they configured the way we want? It gives us it gives other individuals also the chance to do some code review. So let's go and review our configuration.

This is the direct output from the Anthos migrate. And I notice I have one small change here that I want to make. I want to change the cluster name to be the actual cluster name.

And at the same time, I'm going to quickly review do I have anything that needs to be cashed out or pulled out of the of the application at this point here? Everything looks pre configured the way it should be ready for for migration. Let's go and change that in the method in order to make this happen is we're going to use a pull request or merge request here.

And the reason we do this is because now we can bring in other individuals in the organization to say, please, double check, is this the change that we want to do? And in this way, we can see our changes and we see that we basically have an addition. So I'm going to go ahead and submit this.

Typically, you would allow a pipeline to complete fully before you do the the actual merge. I'm going to go enforce it because I know that this is going to work this time. And we're also in a demo.

All right. So we've now merged. We go back to our pipelines.

We can see that we have a new pipeline running with the actual migration. We'll take a look at what this stage looks like. First, we're going to do we're going to do some double checking, make sure that we're not we're going to fail fast if there's any mis fingering sort of fat finger.

So we're in the YAML, then we're going to actually pause for a moment and say, let's do the actual migration. I put a manual switch on this to simulate maybe somebody within your organization who says I want to wait until an opportune time to make that migration actually happen. So in a moment here, this is going to pop over and you'll see a little play button at the completion of this migration, this step does take a period of time, depending on the size of your machine that you're migrating.

This can be anywhere between five minutes and several hours. The machine that we're migrating is about 20 gigabytes of space, and it takes about seven, six, seven minutes in there. Luckily, you won't have to experience that.

I will come back when it's ready. So I'm going to say, let's do it here. Play.

Yae. All right, let's go ahead and pick this back up or our migration has actually happened, we move this in about seven, eight minutes. We're able to create a new container, take all of the existing data on that we that we use specifically targeted off of that virtual machine and bringing it into a container.

So now what's happening on the on the pipeline here is after completion, it's going to output a few more configuration files. These are going to be the file that's used to deploy the application itself to a Cubanos cluster. And so you'll see here that we're reading these artifacts and we're going to be pushing those to the repository as well, so the output we have a post migration file, which gives us what the migration file was actually used.

We do have a profile that gets created. This Docker file allows you for a day two operations to come in and update that original application. So say you need to keep things up to date from a operating system standpoint or you need to install new applications.

You have control over those things. So we'll take a look at our pipeline and we're in the process now of just finalizing the last bits. This is where the CACP pipeline takes all of those files and we're going to push them into the repository.

Again, we're going to follow the same pattern that we did before where we pushed this into a branch, allow you to do some review, some customizations, some changes as needed, and then we are able to go ahead to the deployment. So in just a moment, when these are up here, we will go ahead and perform that out of the box. The original or the the system gives you the deployment files.

You need the deployment, Karriem descriptors, but that gives you a service that's headless. And so you are not able to outside of the cluster, you're not able to target that to target that service that gets created. And this is done intentionally.

So let's take a look at what files were created. So, again, we're going to shift, end and go to the pending folder or a branch. We'll go into our communities file and we'll see that there's now a descriptive file that was twenty one seconds old.

Let's take a look at this. So in here, this is the output and you'll see like here is the upgraded application and you'll see here is the head, the service for shortcut purposes, I have created a service that I'm just going to cut copy and paste just to be fast. And let's go and edit this and make that change.

Add this service in. No, go ahead and do a service here, OK? Commit that change and now we're into a case where we want to make us go live.

So we're in a branch that's not going to deploy. You can choose at this point if you want to make this a deployment to a lower level environment for demonstration purposes, we're just going to have only the master doing that. So, Golove.

And so we create our merge request submitted, and upon merging this, it will merge it into M. The Khedive pipeline at that point will pick up and make the deployment happen. So I just go and push merge.

Now, as this is happening in the background, I want to show what we have. So back to our companies who are Google counsel here. I'm able to do a cubeCTL, get all and show that at this point we have nothing in our cluster.

As this pipeline is currently being run, we will start to accumulate the deployment and the services that that are exposed by that and then we'll be able to review them. And as that's happening, I'm going to go ahead and start on the second segment of this deployment, the last phase that we have, so I will come back to this deployment in just a moment. I want to go to the creation of the companion application.

So one of the two applications is being deployed now. The second one here is our companion. Our companion app is just going up.

And the intention here, as we have a source code, the intention here is it's just a Web front end that serves up that listing page. What I want to do is I'm just going to go ahead and kick this one off the pipeline of the companion app. Just build and deploys the application to the Cuban Army's cluster with a service and an ingress controller that allows us now to split traffic at the highest level from a padding perspective.

And so at that list, we're going to replace it with the new functionality. So from day one, we've automated the process on allowing and enabling a development team to come in and start extracting functionality out of a monolithic application so that you can start losing or reducing the dependency you have on that older application. Let's go back and see where we're at on that first pipeline, the completion of the deployment, and we are ready to deploy.

So we are currently pushing this into urban areas, so as we as this goes, we can go and take a look at cube steel or cube control. And we have now deployed the new modern application. And let's see where we're at on the monolith, so we just deployed the monolith as well.

Let's go take a look here at our Kube cube control. And we have applications are coming up. You'll notice here that our model application is in the state of booting up.

We have four services. We have two that are local and to the republic. And we'll go ahead and take a look at one of these in just a moment.

Once we get an IP address for this. And you'll see that we have an Ingress controller that's being set up from our UI, we can take a look at this in the same direction. This is probably a good point to note while we wait for these services to come up.

And that is one to point out that we do have a UI that just came out a week ago for the animals migrate. You're able to actually walk through this. I started this with the previous version so the containers don't show up in here.

However, if you start out with the latest as of Monday, you will see the containers popping up here. Let's take a look at our services. And you'll see here that we have a load balancer for our monolith application and our Ingress controller is being created, so I'm going to go ahead and open up our service.

And you'll see here is the original service. With although it's not as pretty because I chose to pick to reduce out the HTML content from the original, and so we only see the original old model, that application from this perspective. Now, as we wait for this ingress controller to to pop up, this does take a period of time.

So let's review what we've done. So in the first stages, the beginning of the of the demonstration here, we actually did a set up, we did a source thing for where the image comes from. We did the configuration for the migration.

Then we created two different repositories, one for the for the application and one for the companion up. We're currently in the process of finalizing the Ingress controller to build to override that that traffic that comes in and do some extraction. And we have our different applications that have been deployed.

Let's take a look at our interests here and see how close we are. And we're still currently creating. So this will be the last pause we have here, so.

All right, so it looks like our ingress has been created. We have the green. Let's take a look at what our ingress I've rooted a hostname to make this a little bit easier.

We're able to see the legacy application hit list. And this is the overwriting of the functionality from an endpoint. And as soon as it returns there and then here is the webpage.

We don't have the images on there. My application itself does not do a whole lot. But you'll notice that the difference on here is that I have the applications coming from the going versus the old page that looks very similar to this.

All right. So I hope you've enjoyed the demonstration. Please leave some comments and we will get back to you.