 Hello, Marcus. Hello, Miguel. Hello, everyone. Good to mogen. Good morning. So let's talk today about migration toolkit for applications on how architects use it. First, let me introduce myself. My name is Miguel Perez-Colino. I'm product manager for migration toolkit for applications. And with me is a Marcus who has been doing some migrations in the field. Would you please explain to introduce yourself to us and explain what you do? Yeah, absolutely. So hi, everyone. As Miguel said, my name is Marcus Nagel. I work with the MIA Solutions Practice. So I'm a services guy. I've been implementing a huge number of application migration projects from things like WebLogic onto EAP standalone, from WebSphere onto EAP, and also to OpenShift, so the Red Hat Runtimes on OpenShift. So before I joined Red Hat, quickly, so before I joined Red Hat, I joined Red Hat three and a half years ago. I've been working at IBM for 17 years. And also there, I've been doing application migrations. Well, not to OpenShift, obviously, because that was before that time. But yeah, so that's what I've been doing. Well, that's nice. I mean, and what we would like to know is how do you use the tools in the migrations? So first, I will explain a bit on how would we normally do a migration? Could you click Next first? OK, so there's a process that we normally follow that is discovering what does the customer have. And for that, we have a tool which is Migration Analytics that can help you discover the work running in your infrastructure. So you could say, OK, this is the sizing, more or less, on how many web logic servers do we have, how many top gas, how many web fears, et cetera. And then also we have an assessment for the organizational readiness, which is called Ready to Innovate, which is just to understand a bit of where you stand and the comparison with the average in your vertical. And we have Pathfinder that this is directly for applications to understand the application arena or environment and be able to select, OK, these are the applications that are the best ones to start with. And these are the applications that are going to be more complicated and so on. This is based on a survey that we have been doing in the field for quite some time with customers, helping them assessing the migrations. And then is when the real work starts, when you get your hands dirty and start changing things in the code. And this is where Migration Toolkit for Applications is for. So next, please. And well, Migration Toolkit for Application used to be known as Rehab Application Migration Toolkit or RAMT, OK? The upstream project that is known also by customers is called Windup, just in case you want to go and take a look at it or contribute. I mean, as usual, in Rehab, we go open source, edge to edge. Of course, this project is available to anyone in github.com slash windup. And the tool is available for free in developers that have come to download. Next, please. So Marcus, tell us a bit about the Toolkit. Yeah, right. So since we typically use that in our customer engagements when customers say, OK, I'm tasked with modernizing these applications. I need to move off of a certain application server or I have an EAP application that needs to move on to OpenShift, on EAP on OpenShift. So what we do is we use, obviously, the Migration Toolkit. So that's what we're here for. And quickly, for people who haven't seen it, I encourage you to watch the other videos here on the site because there's a full end to end demo. But a quick introduction is it analyzes your code for proprietary libraries, some dependencies on proprietary JEE runtimes that might be in your code, analyzes for cloud readiness. So would it run in a container if you stuffed it in a container? And it would also help you with migrations, let's say, from EAP 6 to 7, just as an example. And there's various distributions of the tool that you can see here. And that's what I'd like to talk about. So how do we use them, actually, in our day-to-day lives and projects? That's what we want to know. Tell us. So the thing is you would typically first start with Web Console because that is easy to install. It's available as if you can simply unzip and run it. So it's an install in one minute. There's also a version available for installing on OpenShift. And so you can easily set up AVM or install it in an OpenShift in your namespace and make it available to your developers. So typically, you would go in and say, OK, here developers, come have a look, have a you do a quick introduction. OK, this is what the tool looks like. And then let your developers play with it, get a feeling for the reports, get a feeling for the results it's presenting, et cetera, et cetera. So that is the typical starting point we see in projects. And it's also good for smaller engagements where you say, OK, I have like 10 or 20 applications. Why is it not good for larger engagements? Well, from a technical perspective, you could use it. But it gets a little cumbersome to upload. Like, let's say you have 50 applications that you need to modernize. Each application consists of, let's say, one or two ear files, a couple of war files that you need to analyze. So you would have to upload them via a web interface. And that can, I mean, a developer likes to script. So that's what the CLI distribution is for. And that is very straightforward. It generates the same results. So there's the same engine in all of these. There's no difference of what you get. And also, the look and feel, everything is the same. It's just a different way to call it. So as I have put an example here, it's very easy. It's very easy to script it to use the parameters. And the typical use case of that is you have developers put their deployable artifacts somewhere in a directory. And then you would just have a script run through all those directories. And then put the resulting HTML reports in a certain directory. And you can put them easily onto a simple web server, like a patch HTTP server, for example, for consumption. Or you can just keep them on your laptop if you want. But develop is a collaborative effort. If I understood correctly, there's the web interface that you can run on your laptop or deploy on your OpenShift. You deploy it in a couple of minutes because it's a zip file and zip and go and you're ready to go. Or if you want to script it, then you go for the command line interface version that can run for a huge set of applications and generate the reports of each application. Exactly. Exactly. Nice. And so another use case for that together with a Maven plugin is, let's say, you have a really huge application. And you don't want to have one report and then have your developers go. No, typically you would have an iterative approach, agile approach. And so if you want to continuously evaluate how far you are, what findings are still in there, or what happens, I've introduced some new ones. Happens to the best of us, then you can use either the Maven plugin during your build process or you could use the CLI. That's what many customers do, use CLI in your, for example, Jenkins pipeline that would automatically analyze the code and then give you updated reports every time you build something. So Markus, are you telling me that with the Maven plugin and the command line or the command line interface, you couldn't embed the analysis in your CI-CD pipelines and be able to continuously check the applications? Exactly. Exactly. That's so cool. And that's what many customers do, especially if you have a complicated application. You don't want to go through that process, even though it's small. You don't want to tell your developers, OK, now I have this artifact. Please put it in this directory, then rerun the CLI script that we just talked about. That would be an automated fashion and you would always have your updated reports. Nice. And last but not least, and that's what we see at customers, it's like 50-50. So we have IDE plugins, as you mentioned in the beginning. We have IDE plugins for like VS Code Eclipse. And so what they do is they highlight the report, they highlight the findings directly in your code and give you some hints on what to do. So similar, again, based on the same engine, similar to what you get in the reports, but directly embedded in your IDE, which is very cool and I personally like it, but it's a matter of taste. Some developers will say, yeah, that's nice, but I'd rather have my clean development environment and I will just have the report next to my IDE side by side. And other developers will say, no, that's neat. I want to have the issues highlighted in my IDE right away. So it's your, obviously, it's your program. We know that developers normally like to have their own environment, their own choice, and their own way. So the ones that want to have it in line, they have the plugins, right? Exactly. So nice. OK, and one advanced usage in the spirit of sharing is caring. One thing that is often overlooked, but it's very powerful, is you can modify and you can create your own rules. So what is a rule? It just can be as simple as, I have an example here, an XML rule. You can also write the complicated rules in Java code in line. There's a guide for that in the documentation, rules development guide. But it can be as simple as that. So you have already found an issue a couple of times. You have documented, which is a good practice that we recommend in our projects, to document everything you do and find it. Because some other guy will come with an application that faces the same issue. And you don't want them to reinvent the wheel and check out, OK, I have to do this, I have to do that. No, you want them to find what you have already done. And it's easy to add, for example, links here. In this example, I just said, OK, check the Wiki for an example in conjunction with our super framework that we're using internally. Or when you use frameworks internally and you encounter a specific reference, you build a simple rule and say, OK, if you're using this framework, just go to this Wiki page and it will come up in the report. Go to this Wiki page. And this is how you migrate if you're using this part of our internal framework, for example. So that's very easy, very straightforward, yet very powerful. This got to save a lot of time to people. You have a rule that you find an issue that is common because you're using the same set of practices. And then you write the solution to that and then you point your colleagues to that solution so they don't have to overthink it but just apply it. Exactly, exactly. OK, so let's do a quick demo. Let's see it in action. Yeah, so by the way, this is running on my laptop now. So no fancy server landscape in the background. As you can see, this is on my laptop. Running on Linux, right? Yeah, right. Well, we work at Red Hat all of them. So I'm running Red Hat Linux on my laptop. But this is our base, so it would run in a Mac or it would run in Windows, right? Absolutely, absolutely. Perfect. And so I encourage you again to watch the full demo. I just want to show you from a day in the life, what do I do? So I have these reports that those have been generated either via the web console that you see here or the reports. These reports look exactly the same if you generate them via the CLI or the Maven plugin. There's no difference. Same report. The only difference is the way how you start the analysis. And so what developers typically do, what developers typically do is they will jump right into their code and see, OK, what did the tool find? But one thing I quickly want to highlight, again, watch the full video is the target runtime tags here. So I can see, OK, these are supported by EAP, for example. And these things would not be supported by JWS, which is the Red Hat build of Tomcat. So you can see maybe you find, OK, there's only one Red Box. And then you see, OK, if I change this, then I would be able to run it on a Tomcat instead of having to run it on a full JEE stack. So these are just a hint. It's quite a nice feature to see, OK, what would I have to change in terms of libraries or technologies to make it runable on a different runtime? OK, developers will dive right into. They will not really care about the dashboard. This is more like for development managers and application owners. OK, so this is what a report looks like. That's the part I like for me. Yeah, absolutely. But developers will say, OK, now what did the tool find in my code? So you can dive right into it, and then you will see. I will directly go into, here's, by the way, a little more explanation, OK, what did it find? And some references. And these references would be, they could point to your internal wiki, as I've just shown, with your rule. And I will go jump directly into the code and say, OK, now this is what it has found. And now, sadly, there is no pixie dust. So your developers will have to use their brains. Well, obviously, you have hired them because they have brains and good ones at that. So yeah, as a developer, you will have to look into it and see, OK, now this is a suggestion. This is what the tool has found. And now I can say, OK, I will change that according to the findings. But also, sometimes maybe you're using a certain framework, or you have policies on how to apply different patterns. Then you, as a developer, have to decide, OK, this is what the tool said. Can I directly apply this? Or would I have to probably refactor the code a bit? So this gives you very good hints. And it says, OK, you cannot use this. Well, obviously, you cannot, for example, use a WebLogic library or WebLogic class that is proprietary if you're using it on EAP. That's clear. That's very obvious. But there might be other changes where you have to think a bit, OK, can I use that directly? Or would I have to refactor my code a little bit more? So this is how developers in the field would directly dive into their code and say, OK, these are the things that the tool has found. And yeah, you will still have to use your brain. But that's what you're here for. Let's say that in your experience, this is normally a apply, I mean, verify that it would work, apply, rebuild, and retest. Exactly, exactly. Most of the times, right? The other ones are exceptions. Yeah, exactly, exactly. So in your project, you would build your target environment and probably in your first try is it wouldn't work. And then you would see, OK, now let's analyze it, let's analyze it, and see what the tool says. The thing is, it should help you, and it will help you with identifying things that will not work on your target runtime, that will not work from your code unchanged in a container platform, or it will cause problems. The trickier ones are the ones that work and just cause unwanted behavior. So there's also a huge number of rules that help you with containerization. And then you would apply the findings here. You would have to look, OK, can I use that directly, or are there limitations? Because my company policy says, OK, don't use this. Might be a suggestion from the tool, but maybe you're not allowed to use library XYZ, and then you would have to come up with a different thing. That's a really good example. Thank you very much, Markus. I think that it is pretty clear how you, the architects and consultants from Red Hat, use with the customers and developers the immigration toolkit for applications to really perform the final steps of the migration to open source platforms and open source products. Thank you very much, Markus. You're welcome, and I hope you enjoyed it, and there's a couple of takeaways from you that you can use in your projects and using the tool. I'm sure there will be. Thanks. Bye. Thank you. Goodbye.