Mike Ensor & Kurt Dusek – Automating Modernization with Anthos Migrate

We've heard a lot today about transforming process and metrics and management, but we haven't talked about transforming your actual applications. That's why I'm very excited to have Mike Ensor from our sponsor, Google and GitLab's Kurt Dusek talking about how to use Google Anthos along with GitLab to do just that. Let's take a look.

Hi, my name is Mike Ensor, and I'm here with Kurt Dusek, and we're going to be talking today about modernizing your Your migration's with Anthos. So in this talk, we're going to cover digital transformation, how that kind of applies with Anthos. We'll talk a little bit more about how you make transitions between VMs and containers.

We'll go through some strategies that might be important to think about when you're looking at migrating legacy applications or VM based applications. And we're going to talk about the how you might modernize that by using automation and enabling and setting yourself up for Day 2. So to start out, We have to recognize that the industry has there's a large cost to legacy applications.

T. organization is typically put towards old legacy applications. They typically are Java and dot net, whereas only about twenty six percent of that spend actually gets pulled back in and used for innovation.

And so you don't get a lot of future thinking. Now, when you're looking to do some sort of a digital transformation, you want to you want to move from a legacy based application set and you want to start moving somewhere else, you have to think about what is the easiest approach and what can I do where where are the some shortcuts? Now, the nice thing about this is that there's been tons of studies around Dora.

There's been studies with McKinsey and multiple different organizations that have now come back and universally said that if you use modern tools to make this migration happen, you tend to see a quicker time to success. And you come out at the end with a running operation as though you've always been kind of a digital native or a cloud native application. So one of the things that we try to pull out of this are going to be things like you want to be able to reduce your risk, you want to have quick time to market.

You're looking for cost efficiency and, of course, the quality as well. So this is where from Google, this is where Anthos comes in. We put together a series of tools and processes and products to help enable you give you the ability to do transformation from old legacy style, typically waterfall based type of deployment or management into a very shift left or a very common group of individuals who all have a single purpose to build the applications of their domains.

What Anthos provide you as we give you the ability to focus on the applications that you're working on, not on the infrastructure. We build a significant number of our services to give you kind of be serverless feeling and you can develop your platform yourself to have a serverless feeling. We also want to meet you where you're at.

We recognize that there's a large gap between being on-premise and running in a cloud is a lot of steps that can be taken. And so this talk in particular is going to cover one aspect of that. Anthos itself has multiple different tools and techniques that can meet you on all the different levels that you might be operating at, from everything from geographical to sizing to different types of data, data servers and data sources that you're working with.

And most importantly, what we want to do is we want to give you a single point of reference where you can go in and see these operations and see all of your infrastructure that gets put together and largely make it opaque for your development teams so they don't have to focus on the infrastructure. One of the key tools that we that underpins the entire Anthos platform is Kubernetes. At Google, we have the Kubernetes engine or the Google Kubernetes Engine, the GKE.

And this is offered both on premise, in AWS and also in the cloud. And what this provides you as a portable layer such that you can, providing you're using containers, you're able to then push your applications to any one of those locations, whether it's the on Prem or Cloud or AWS, it gives you a universal platform. So when you start talking everything within the Kubernetes ecosystem now, you can start consolidating your toolset so you can consolidate your IT learning and spend into a more direction directionally oriented towards the Kubernetes benefits and the Kubernetes style.

And lastly of this, this provides you a new mechanism in which you can use automation. There's a ton of technologies out there. There's a ton of open source tools that all help you with this automation.

None of this is proprietary, which allows you to then open up and use a very, very wide amount of the community tools and not get locked into just any one particular method. So. We're probably taking this step right now and we're saying, look, I'm on a VM right now, I like the idea of containers.

Some of my new applications are already taking advantage of containers. What do I do in the case that I need to start moving my applications? We have a couple of different approaches in which we go at this.

First We have this concept of a lift and ship, and this is literally taking the bytes, the bits and bytes from the actual box that you're working on and migrating or streaming them directly into some sort of a VM or container at the end. The idea is that you have a like for like a single instance of something. And when I'm done, I have the instance primes, so to speak up the same.

Along with that, we get to utilize the other tools to kind of come along with for a ride. So one of those being we have a good partnership with with GitLab. And in that partnership, this allows us to have, not only do we use the tools that we've been developing within Anthos those for your migrations and for your observability, but we also get to utilize the best in breed breed technology for the continuous delivery and making sure that the entire process that's gone from the virtual machine all the way through the deployment is done on a very solid platform.

And that is the that's where that's where GitLab comes in. So when we think about modernization, a couple of different strategies come to mind. I have a kind of a cool graph on the left that really shows both.

If you're on prem, if your traditional, if you have native apps, if you're in the cloud. And really what it comes down to is there's a there's a few major categories. If you have a brand new application migrating to the cloud is easy as you just build it initially, as you would from a cloud native, if you have an existing application and it's built into a container and deployed on an on premise, then the move is fairly easy.

You can just re-leverage those those instances of images and and possibly change a few YAML files, config files. But you can redeploy onto a cloud. Where things start to get a little tricky is when you get into applications that have this niche, this this piece to it where maybe you don't know what's on that server.

Maybe it was developed by a different organization. And you like a consulting company who came in and you no longer have source. Or maybe it's treated more like a snowflake where you go in and every single server is different.

Often there are middleware applications like Web logic where you can't just rebuild that server. And so you need to take the entire contents of that server. And that's those are the types that we're going to talk about here.

There are generally two approaches. When you're looking at the the lift and shift style here, you can either modernize and move or you can move and modernize. And the differences between there, if you modernize and then move, that's generally a slower approach and you typically only pull out the pieces you need.

But you also have some challenges in that you're not going to be able to use the agility of a modern like, say, a Kubernetes engine to build a spin up new side projects or new resources that might be interacting with your legacy application. Whereas if you move and then modernize, it gives you the flexibility when you're in the cloud to make the changes you need to do spontaneously or very, very rapidly without having to wait for IT. So we're going to focus a little bit more on the migrate, then modernize.

And that's kind of a good pneumatic. Sounds good. So first, why do you want to containerize why would you want to containerize applications that are VMs?

So it seems like you're you're fitting a square peg into a round hole. Well there's a couple of cool things that come out of this. If you start thinking about your typical VM or instance that you're working with, they tend to be, if built the right way The first time, there's one application on top of an operating system on top of a version that is a virtual machine.

Those are pretty straightforward and pretty easy to set up. You've done what you need to do. However, almost most of the legacy applications that we work with typically aren't shared resources.

So you do a lot of unpacking on those virtual machines. You've been giving them one virtual machine. And so you're going to take advantage of it and you're going to maximize everything within that system and maybe run three or four applications.

What that does is that sets you up for a higher degree of fail. If one system goes down, you have a broader range in which those errors, it's not just the application goes down. You have these inherent coupling with the other systems.

So moving to a container based system, we have the ability at that point to start extracting those applications from that one VM and we're going to rightsize them, make them purpose, purpose built in right size so you can kind of change the way that your density works. Now, the nice thing is that a virtual machine carries the cost of running an entire operating system. Oftentimes, if it's a has desktop oriented features to it or has large systems, you're running an entire operating system, but really you just want a single binary.

So extracting that out is a one method in which we can also reduce costs, but also make them more purpose-built and lightweight. T. organization, let let those developers know those IT Ops who know how to operate all the way down to kernel level of VMS.

Let them let them free them from that. Let them actually move into the areas they want to do, which is typically more new, more modern with with containers and and maybe focus on different areas within the IT organization. So if we start consolidating those now, we have an operational efficiency that we're gaining by bringing in a new toolset.

So then the question is, I've got to bomb how to make into a container. So there are multiple different methods in which to do this. But I'm going to introduce one that we have.

It's called Migrate for Anthos. And what Migrate for Anthos does is it allows you to byte level copy stream up any VM that exist with a few conditions, operating systems, typically its limitations. We support a 16 - 18 operating system, but if you fit within that very large, wide range, we're able to automate that process of migrating it into a container.

I won't go into the details of all that. You can find most of that on the public website. But suffice it to say, it comes into a container at the very end and you're able to then turn around and deploy that container into a Kubernetes instance.

So where does Anthos Migrate fit? So it's a good fit when you're looking at applications that were typically more enterprise oriented or like happen to have middleware based logic tiers, like ISS7 or ISS based when your looking at Web logic, those types of applications, those are really great targets that you might use for migrating from a VM into a container. I will say right now that if you can rebuild your application from scratch and you can deploy it without using that VM, don't use the migrate Anthos Migrate, go straight to just deploying it out, as you would from any normal development process.

However, the vast majority of the systems that are out there that are legacy still have those baked in flags and switches and configuration settings and things that you're not entirely sure on that system. Those are the ones that are best tackled. So I like to call those the opaque servers.

Things that are not a great candidate would be if you're using VDI or desktop apps like thick apps. Those are not really good candidates you're trying to depend heavily on GPUs or TPUs those are typically, again, not really good candidates those would be really good for a VM migration. So if the goal is to just get off of a dependent data center, you can use what's called V to V, which is VMware or to VMware, and it does a global copy of those.

And so you get the exact same server and you can migrate that at, but it'll still be a GCE instance it won't be a container. So at least you've minimized the disparate disparate systems between the two on Prem and Cloud, but you haven't quite fully pulled it into container yet. So what this brings you is gives you the ability.

We now can can essentially call this a unified migration data platform. We can suck in sources from VMS to VMware to Azure, AWS, all sorts of remote. There's multiple different upstream sources that exist that then get pulled into through a series of what looks like magic.

The team worked really, really hard to make it so it looked like magic. And it comes into this this this location, which creates an image. And then you can then go and deploy that.

Right. So in the background, it's actually using KRM based tools. And so these are all CRDs in Kubernetes world the custom resource definitions.

And so if you're familiar with Kubernetes tools using this process, you can use it straight, straight, and we feel very comfortable. It had had you been really good with Kubernetes already. If you're not there, are UIs that are very helpful that walk you through this this process from source to completion?

Now, the rest of the talks kind of going to be focused on. It's great that we have these multiple sources. We can pull us in.

But as you can see, that is probably now we have this this this opportunity for doing a repeated process. And any time I hear the word repeat a process or I can say the same thing two or three times in a row, I know that we can automate it. And our goal as software developers and operations should always be thinking about what can we do to operate, to remove ourselves from making human errors.

m. phone call. So.

So what types of approach might we want to take here? So initially we probably want to look at all the different workloads that exist and want to evaluate them for the criteria that I had stated previously. Again, on the public website, there's a ton more on there of different ways you might want to look at it.

We can also come in and help out with that as well. You target what you're looking for and you want to generate the you want to put this into the engine and then have the engine spit out all the artifacts required to make the operation happen, to make the migration happen. And then you want to operationalize that.

You want to build or deploy those. And what's nice about this is we actually have distinct phases. This gives us the ability to actually look at what artifacts are coming out and make sure that they're appropriate.

So in the first phase is typically just a one time deal, you set it up, you're going to be setting up your system, not a big deal. This is usually about where your sources come from and making sure that you have authentication and whatnot when you do the actual migration we have this process in. It looks eerily similar to a CI/CD pipeline, which is one of the reasons why we love using GitLab is because they they are the experts at the CI/CD pipelines.

And so we're able to take this and transpose this process directly into steps that happen in CI/CD pipelines. Later on in the demo, you'll see exactly that. So what you do is you generate your plan.

So it gives you an opportunity to say, is this right? Am I getting what I need out of this? Do I have the right names of my deploying to the right location?

And when eventually goes to Kubernetes, are we using the right cluster or are we doing the right nodes? We have some tolerances. Do we need any of those?

This gives you an opportunity to review this also at the same time with a CI/CD. This gives you an opportunity to do a code review and get some auditing into your your CI/CD pipeline flow. Once you're able to test it and deploy it.

You can continue on with that CI/CD pipeline and consistently keep rebuilding your application over and over again to keep it up to date. One of the artifacts coming out of out of the Anthos Migrate is a Docker file. And in the Docker file, you're able to modify it and update it and then keep pushing that out.

So every single update that you need will keep pushing out so you're not stuck where you're at. So let's talk about how we all put this together. So in the demonstration we're about to give, you're going to see that we have one big VM server and inside that server we have two applications.

I want to demonstrate that while we have two applications, I'm only extracting one of those two applications. I don't want the second one or the first one. I only want the second one.

So we set up a configuration to pull directly from that. Then we're able to run the migration and push it into staging the push into production. Everything's pretty straightforward and covers up a lot there in that short slide.

The second thing I want to introduce here is I want to give us an opportunity to say, are we modernizing this for Day 2. So the Docker file updates are one way of doing this. But that's not the way you want to live for us.

If you're just migrating just to make it a container and live there forever, it's not the most ideal solution. So what if you enable your developers to say when you make this migration, you will automatically have a method in which you can start extracting services? And so this diagram here kind of describes like on day one, you start with the legacy application.

Everything's copasetic, it's great and you're great. But now you say, I want to start extracting those services out of there because I don't want to live on this legacy. I don't want to be dependent on this legacy application forever.

So you create a second repository and you start siphoning the functionality out and you're using engrosses or API gateways to to drive to that traffic up. Over time, you start creating more and more applications. As that happens, your model will begin shrinking and getting smaller.

And so in our demonstration, this is exactly what we do. So we do the entire setup of our migration. We get down to the point where when we go to create the actual work that's happening, the actual bit copy migration, we're going to create two repositories.

We're going to have one that's going to contain all of the functionality and all of the output and artifacts that are coming from the migration itself. And we're going to create a companion application that will work with it. In that companion application we're creating, we're we're hooking into an ingress controller.

That means that once we have the fully migrated application up and going, we can now turn on our companion application, which is going to start extracting information or intercepting calls into that primary, a monolith in order to use that for the monetization effort. Over time, you might have two, three, four or five micro services that go along with that repository. Great.

Thanks, Mike. So let's recap. How does GitLab fit into using migrate for Anthos?

GitLab enables cross team collaboration by using Merge requests to manage changes to your application code, base and configuration files. So using Merge requests to encapsulate change gives us a few key benefits. First, we can report on how each change is potentially affecting our compliance status, our security posture or our code quality.

And we can apply approval rules and select individual groups, individuals or groups of individuals as code owners for specific parts of the repo so we can automatically engage the relevant approvers based on what change was made. And so we're also using GitLab to store our operational workflow as code, and that allows us to run CI pipelines and that enables anything from running security scans and unit tests to provisioning the necessary infrastructure that we need to run the app. So we're also it's more than just creating repos and we're actually leveraging GitLab and taking that a step further.

And so we're creating project templates and that allows us to define the assets and the configuration that each of the migrated apps might need. And that gives us consistency in the output and keeps things flexible so we can handle changing needs or accommodate the occasional one off. And so lastly, GitLab has the ability to tightly integrate with your Kubernetes clusters so we can deploy namespace environments with specific configurations.

So this is going to make it easier to test the phased migration projects. And we can also get Cluster Metrics from Prometheus and then view the health and log's of the individual pods and also connect to those running pods via the terminal. So that's basically it for us.

Thanks very much for, ah, for attending.