 Oh, hello, everyone. This is Miguel Perez-Colina, I'm product manager in the Modernization and Migration Solutions team. And I want to talk to you about migration toolkit for applications. But first, a bit of an overview, OK? There's a whole related tooling around application modernization and migration, OK? So there are several phases in every application migration phase. There's the discovery phase, there's the design phase, and there's the deploy phase. So we have tools for each of those phases and different personas that are involved in them. So in the first phase, the discovery phase, we have migration analytics that is around discovery. It's pretty focused on infrastructure, but it provides quite a good set of information on the inspection of the workloads or running on virtual machines. Then in the design phase, we have ready to innovate to assess the organizational readiness to move to a hybrid cloud. And then Pathfinder, that could do an assessment on the cloud readiness of the applications that you could have in your own environment that you are developing. And last but not least, when we go to the deploy phase and we really want to go deep down into the application itself, we have the migration toolkit for applications, which is the application that I'm going to, the tool that I'm going to demo. So about the tooling portfolio, getting a bit more deep, just tiny, okay, on each of the tools. Migration analytics is a tool that you just need to deploy an appliance on your VMware environment connected to your big center and it will extract the metadata of the VMs that are running there. And it can report you several things that could help you make a decision on a migration. It's pretty oriented to lift and shift, but again, as I said, it can help you discover middleware run times and JDKs, and of course add savings to the migration. So what does it provide? Saving estimation on a migration and lift and shift for VMs to build the business case. Then a world of migration summary, which could provide a list of the workloads found and the issues, well, issues, the unestimation of the efforts that could appear on the migration of VMs. And again, when I was talking about the issues is that we can avoid many issues because we could detect the complications that could appear during a migration before it happens. So the migration goes as smooth as possible. And then the workload migration inventory with a full list of VMs and workloads in which we could find, for example, how many web logic application servers we have, how many top-tier application servers, how many Microsoft SQL databases are running and what is the size of each of them. So we can consider them for migration. Not just lift and shift, but I'll report for me in many cases and in some cases for rebuild depending on the application itself. So next step, ready to innovate. In ready to innovate, there's an assessment of an organization that has five points, architecture, automation, ways of working, working environment and leadership ambition. So we help you assess from the technical part to the organizational part of your environment of your organization and see where can you improve. So you are ready to be able to move to cloud and to adopt the new methodologies that are available, such as DevOps, Agile and so on, in case you are not already using them, of course. So in ready to innovate, we perform a questionnaire and take the details from each team, from operations, from development and we put them together, we consolidate them in a very nice graph that looks like spider web. And there you could see the five points that are being assessed and be able to see in which one you are above the average or below the average. So you could put more effort where it's more needed when it comes to investing in the organizational parts of your own company and be able to innovate ready to move to cloud and to move to the open and hybrid cloud. Then we have Pathfinder. Pathfinder is a more tactical tool. It goes more into the application themselves, but what we do is we do an assessment with a questionnaire base that it could help you discover the status of each of the applications, how well maintained it is, how it is being handled, how it is being deployed, what are the dependencies, what is it running on, how ready is it to be containerized, how ready is it to become cloud native. And then once the questionnaire is filled, you can review it with an architect and establish proposed actions if you want to rebuild or retire or replatform on applications. You can make an effort estimate on each of the applications, assess the business criticality and establish a priority. So after this, you could say, okay, these are the applications that make more sense to start working on to bring them to the cloud. So it helps you identify the best targets for you to start working on to provide you with the best benefit. What else migration took it for applications? So I'm going to talk about it. Migration took it for applications used to be known as Red Hat application migration took it. So in the migration and modernization solutions team, we are consolidating the tools and renaming them as migration took it for visualization migration took it for containers. Migration took it, of course, for applications. So this one is going to be the next version of the Red Hat application migration took it, which will be version 5.0, which will be very likely to appear by the end of July 2020. And you will be able to use it. And again, it's very easy to use. You only need a machine with JDK. You can download it as a zip file and zip it and run it. More details now. But let's go in detail on what it does. So migration took it for application. What it does is that it can examine a binary of a Java application that is being already built. I could also work with source code. Usually it's done with binaries. We put a set of binaries and it scans them and it checks what classes are being used and how they are being used. So it can provide you a good overview on which ones are, for example, specific to a proprietary application server, such as WebLogic. So if you're using a class that is specific to WebLogic that is going to stop you from bringing your application to cloud, then you could consider changing the class that you're using. So what else? We can also help in Javas upgrades and Java EE upgrades. So we can check on different versions of Javas EAP or the standard Java EE and tell you, okay, this one is being deprecated and you should change it. All this one requires some modifications, okay? What else? We are adding Springboard to Quacus rules. We have some rules on Tomcat migrating to Tomcat. So if you have applications that are very simple and do not really require the Java EE profile, but Tomcat is good enough, we can help you check which one of them are suitable to be moved to Tomcat and of course, suitable to be able to be moved to containers. For that, we have rules on cloud readiness and characterization that are based on the 12 factor app definition. What we do is analyze the applications and check which ones are having behaviors or do have components that are not suitable to be a 12 factor app. And then we flag them, we reveal them. So you can make changes and we can propose also in many cases the change to be able to be done to each one of those parts that require modification. If you want to add your own rules, of course you can, you have them pluggable. So we are delivering these in four ways. One of them is the web console, which is the most straightforward to use to just go into the web console, upload some applications, which I'm going to show right now. And again, as I said, you only need a machine with a JDK running on it. We have the command line interface, which is really good for scanning a huge lot of apps whenever you have them all together and you just want to go through them one after one or even to embed it in pipelines like JDK pipelines to could simply deploy migration tokens for applications and run it as part of the build. We have, if you want to go a bit deeper, you could even have used the made in plugin to really run it during the build. We also have some IDEA plugins for Visual Studio Code and for Eclipse and for EclipseJ and for Code Ready Studio, which is our created version of Eclipse that of course you can use and you can review while you're coding. So as you see, we have tried to go in every single step of the development process to help bring your applications to open source application servers and to containers and to the cloud. So let's go for the demo. Let's go for the demo. So let's go to the terminal. I have here the web distribution. Right now it is unseaped. So as it is used with the middleware components in Red Hat unzip and go to just unzip it, click on run MTA. If you're running on Windows, you could be on the run MTA dot path. In this case, I'm running Fedora so and I have our JDK. So I just start the application server and all the components that are part of the migration toolkit for applications and then I will be able to use it. This is the version with a web console. So I can run it easily on my laptop and be able to access it. It is pretty interesting that that this could be also deployed on OpenShift. So right now we have a template. So here we have templates. Just have to put this template in your OpenShift and it will be running right there. We are working on an operator to make it not just deployed but also maintained. So right now, if you want to run it on your OpenShift environment, you could do it and it's very well described in the official documentation. So this is a starting app. We can go to a browser. We go to localhost 8080 and it will redirect us to MTA dash web. It's probably not ready yet. So it is loading. And in there we'll find the web console for the Migration Toolkit for Applications. So let's give it a couple of seconds to start and here it is, the web console for Migration Toolkit for Applications. So it is starting up and now we'll be able to create, the first thing we do is create a project. We can create a new project. So I name it normally after the name of a city. So I'm going to go for Kodoba this time. Okay, so this is Project Kodoba and we select a set of applications. So let me choose some files that I have. So I go to Migration and I go to sample apps and I get my sample binaries and I select these five binaries pretty straightforward. I upload them, okay. Go next and then we can configure the analysis. We have the rules for migrations to EAP. This is of course Java EE based. So we have all the rules here to check if your application is Java EE compliant and if you have any class that it is not. We have also the containerization rules. Again, as I said, these are based on the 12 factor app definition. So you can check it. We have some rules that are for Linux that it could be quite interesting to see. For example, if you have Windows paths hardcoded in your applications. So there are several rules that if you are moving an application from JDK on Windows to a JDK on Linux, it will be checked. And then open JDK, just in case you haven't seen any specific class that is not related to open JDK but a proprietary JDK, well, proprietary. Yeah, proprietary that requires license JDK. So right now the tool is identifying the packages in the binaries and in a couple of seconds it will show the list of packages that I can review. So in here we have the way to use custom rules and custom labels in case I would like to use them. Custom rules, custom labels, you know. I'm not going to use it for this demo but this is a good way to be able to customize the rules in case you want to add some options in case they are needed. So I'm going to use a vanilla and let it identify the packages and analyze them. So I'm going to check just for the application packages. I'm not going to go for the third party packages and I click save and run and then the tool will start performing the analysis. Okay, it will queue it. You could run many analysis. At the same time, you could add more applications and they will get analyzed. You could create another project and start running it and you could change it here going from one project to a different one. So right now as you see, analyzing the applications it will take some seconds, not even minutes usually. So let's give it a bit of time. So once this is done, we could check here the analysis the outcome of it and we'll be able to review all the parts that have been analyzing in this set of applications. So let's give it a couple of seconds. Meanwhile, we could check the configuration just in case you would like to change it. You could go here, click it and then save and run and you will start a new analysis. You could remove some applications in case you would just want to check just a couple of them instead of the five that I have and be able to with the same analysis add a new custom rule that could be useful for you. So let's go to the results. Yes, okay, it's getting ready. 280 classes out of 1,445, okay, 300, we're getting there. So one minute, two minutes. This is the list of applications in case you would like to check one by one. So back to the analysis results. It's going to finish in a couple of seconds. Here we go, almost there. And okay, so this is a live demo as you could see. And there we are, turn left. Turn left, okay. So the analysis has finished. So we click here and we get the results. So we see the application list. We have five applications. So I really like this one. It's a very simple application that is useful for Jboss demos. So as you could see, it's fully compliant with Jboss AIP. I can click here on Jboss AIP and I see that these green ones have here the legend. These green ones are the classes that are supported by Jboss Enterprise Application Platform. And the other ones are neutral, no problem. And then we have Jboss Web Server. So here we'll see the classes that are not suitable for Tomcat, for Jboss Web Server. And in yellow, the ones that are partially supported, okay? So we could go to other applications like this one. And here we'll see that we have an unsupported class that was a WebLogic WebXML, which is specific to WebLogic. So you probably would like to have a standardized set of classes using your applications. And in case you would like to move it to Jboss Web Server, you'll see that there are many more that are related to JEE profile and that shouldn't be used. So we could take a look at the list of issues and see which one is the most common one. In this case, we have the WebLogic proprietary logger. So many applications. We found 35 incidents for this, okay? So it's a trivial issue. It's really easy to change. It's just a one by one library shop. And we could take a deeper look in here and it will show you, okay, the detail and why it is not supported. And you could see here the classes that contain this issue. Same thing with, for example, the WebLogic startup service or the JMS descriptor or other issues that could be in use that could affect the migration. So you could just take a look at, for example, this is the Cloud Mandatory. So the way we are doing remote method invocation service, well, we could see the details on why this shouldn't be used for a tough factor app, even if it's okay to use it in a JEE server. And more details on other issues on our incident farm. We could also take a look and overview on the technologies that are used. We could show them here. So you could take a look at which technologies are used in the applications and which one are using each one of them. So this provides a very good overview on them. We can take a look also at the dependencies graph. This, what this does is it shows which classes are used by more than one application. For example, we have this application. We could see it here. This is the duplicate test, okay? That is using two classes that are also used by this application, the JEE example app. We could, for example, okay, I don't want to see the worst, just so I click here and they disappear. I don't want to see the embedded walls. I could remove them. If I could also remove the embedded jars and just take a look and what are the dependencies? What is the dependency map? And it will show you a well-detailed list of dependencies between applications when it comes to common classes. We could take a look at the list of the dependencies here. So in case we want to check each one of them, okay? And check the versions or check the jars that are being used and so on. So this provides a full overview on the application list, but we could go to each application and take a look at the detailed it, you know? So let's go to this simple sample app and we'll see also a good overview on the efforts, the incidents and story points that would be required. The ones that are mandatory, the ones that are optional, the ones that are potential, the ones that are cloud mandatory in case you're thinking about moving the application to containers and make it more cloud native and the ones that are informational. So this also helps you provide, have a good view on the effort that each application is going to require and the kind of incidents that they have to be able to plan accordingly when you're going to migrate these applications to open source application servers and to containers. We can take a look at the issues, categorize, same thing, but with just one application. So in case someone is going to go and review one applications, go go to these issues and could check one by one and check again, the rules and the details on the rules and the suggestions. For example, we could go here and take a look at the login quick start on JVOS to get a good detailed introduction on how to manage the logs when you're running it on JVOS. What else? More details, you know, the efforts, the story points measured in the story points so you could assign them to the teams that are working on migrating the applications. The technology is used, but detailed for each one of the applications so you could check each one of them and the dependency graph just for this application and again, the list of dependencies. We can check on remote services and more details like enterprise of beans and server resources that could be helpful to whenever you are really getting in the details of this application itself. So with all this information, you could go edit the application, change it, recompile it, even you can run this test again to check that you didn't leave anything behind and once it is modified, you could go back and test it in your new environment, probably the hard open shift on containers and check that it's running okay and then start using or enjoying the benefits of running on the hard open shift. With this, there's one more detail about Migration Toolkit for Applications. We have plugins, one for Eclipse, one for Eclipse Che, which is the Eclipse version that is deployable under OpenShift, that you could run it under OpenShift and also for Code Ready Studio, which is our creative method for Eclipse, but we also have a plugin for Visual Studio Code in case you prefer that IDE that could help you perform these checks within your IDE directly. So thank you very much for listening and I hope you have enjoyed it and I hope you use Migration Toolkit for Applications. Please do not hesitate sending us an email to migrateandraha.com if you want more information or if you will have your own comments or suggestions. Thank you very much.