 Hello everyone! Welcome to this demo for the Migration Toolkit for Application 6. Today we'll be showcasing the onboarding of a classic Tomcat application on OpenShift. The user experience in MTA 6 now revolves around the application inventory, allowing organizations to have a holistic view of their application portfolio. The inventory also offers seamless integration with other tools, like the assessment and analysis modules to surface information about the portfolio at scale. Applications can be classified and grouped in multiple ways. For example, we can use the business service for this. Let's focus on the retail applications now. One of the key features of the application inventory is an extensible tagging model that allows you to classify applications in multiple dimensions. We've added tags that represent the application technology stack, like Java, Tomcat, and Oracle, and added an additional tag representing the usage of a custom corporate configuration library. Make a note of this, as configuration is one of the key concerns when onboarding an application into the cloud. Since the legacy application comes from a traditional platform and we're aware of some problems with the configuration model, let's focus on this one for the assessment. The first step will be to enter the different stakeholders involved in the assessment. The assessment is driven by a questionnaire aimed to determine the suitability for containerization for a given application. It covers all the different areas of the application landscape, including technology, architecture, application lifecycle management, licensing, and associated processes. These questions enable the tool to identify potential risks that might prevent the application from running in containers or may require an adjustment. Let's get forward to see what risks were found for this application. The review screen shows you the risks identified during the assessment, so you can decide which migration strategy to follow based on that. In our assessment, MTA found some medium and high risks. We can look at them by scrolling down to the list of risks. It looks like the application uses a discovery mechanism that is not cloud-friendly. That makes sense because it comes from a classic platform and accesses a database through a static IP. As stated before, the application is using a custom configuration library that happens to load configuration from multiple paths on the file system. That is definitely an anti-pattern for cloud deployments, so we need to find where that library is used and replace it with a more cloud-friendly approach. Since changes are required in the source code to adapt the application, we can use the refactor strategy. We believe only the library needs to be replaced and should require minimal effort. Since this has been identified as a key application for the business, criticality and priority should be set to the max. We can now save to check or adjust later on if we want to. It's now clear that we need to dig deeper on the customer's legacy application to identify the problem with the config library that it's using and how to remove it. For that, we can use the analysis module available in MTA. For the analysis of the application, we'll need to retrieve source code and artifacts from corporate repositories that have restricted access. The URLs for the repositories are stored in the application profile, and in order to access secured assets, MTA lets you manage credentials in its administrator perspective. First, we'll create a source control credential to access our Git repository. Next, we'll create another credential to access our Maven artifact repository. MTA allows importing a XML settings file for that. The credentials management system in MTA has been modeled for administrators to create and manage credentials, and for architects to assign them to applications without necessarily knowing their contents. Let's assign the credentials we just created to our customer's application to get started with the analysis. We just have to select the credentials we created to have them assigned to the customer's application. This can be done with multiple applications as well. With that, MTA is now ready to retrieve source code and artifacts from the corporate repositories. So we're good to go to start the analysis. The first step on the analysis wizard is to define the analysis mode. MTA 6 includes a new mode, source and dependencies, that retrieves the application source code from a source repository, parses the POM file, retrieves all the dependencies from an artifact repository, and adds them to the analysis scope. This provides a full picture of the application and its dependencies, which is especially helpful when some of them have a provided scope and are made available to the application directly through the application server or the servlet container. We will be using that mode for the current analysis. Next is the selection of the migration targets. We want to deploy our application on OpenShift, so we need to select the containerization path. Also, to make sure we can use the supported OpenJDK images without surprises, we select the Oracle JDK to OpenJDK path as well. Finally, since we're moving towards Linux containers, it makes sense to do a sanity check to avoid any Windows paths that might remain in the code from previous iterations. MTA 6 streamlines the user experience by selecting what should be analyzed. Users can stick to the application and its internal dependencies only, or force the analysis of all libraries, including known open source libraries. Advanced users with interests in specific packages can specify them directly. For our use case, we'll stick with the first option. MTA uses an extensible rules engine that looks for antipatterns to find what should be changed for the application to run in the target platform. To remove the problematic configuration library, we developed a custom rule that looks for any usage of the library and recommends changes to be performed to replace it with a more cloud-friendly alternative. To use the rule, we only have to upload the file containing it during this step of the configuration. There are multiple options to fine-tune the analysis, like specifying the source platform to reduce analysis time. For the moment, we'll stick with the target path only. Lastly, we're presented with the configuration summary for the analysis. By clicking Run, the analysis will be scheduled and begin shortly. MTA 6 fully leverages the resource management capabilities of OpenShift to scale the analysis based on the available resources on the project in which it has been deployed. Individual analysis pods for each application will be created, and the analysis will run as soon as there are resources available. We'll fast forward to the completed analysis and view the report that is generated. The main report view provides a summary of what was found on each application. In this case, one small issue was found on the dependencies, and something minor was found on the application source code. The effort required to migrate an application is expressed in story points. There isn't a direct translation between story points and work hours, since each organization has different teams and skills, but they do provide a way to compare and understand how complex migrating an application can be. Now, let's dig deeper into the application source code. First, we're presented with an overview dashboard displaying the incidents found during analysis. Actual details can be found on the Issues tab. The Issues report provides exact information on what needs to be changed for the application to run on a target platform and allows the user to drill down to the line of source code where the problem was found. Issues are classified and organized in categories. In this case, two cloud mandatory issues have been found, which are related to our findings during the assessment. It looks like hard-coded IP addresses were identified. Clicking on an issue provides hints for what needs to be changed and the exact file list where the issue was found. Here, the hard-coded IP issue comes from a configuration file. Selecting a file navigates to the file itself and highlights the issues found on it. We can see the problem is with the IP for the database, which should be easy to solve. Let's return and find out more about the second issue. We can see that our custom rule was triggered and usage of the custom configuration library was found on the source code. Along with hints on how to resolve the problem, the report can provide code snippets and links to external documents. Notice that the issue was found twice in the same Persistence Config class. We're able to see exactly where the configuration class was being instantiated and get suggestions for how to replace it right into our source code. In addition to viewing critical issues, the report provides a lot of other useful information. For example, the Technologies Report provides a detailed summary of the technology stack for the application, which is especially interesting when dealing with large portfolios in which the details about each application were scarce at the beginning of the migration initiative. Another helpful report is related to dependencies on the application list. MTA-6 is able to identify open-source dependencies by their hash and provide their associated coordinates within the Maven central repository. This helps with legacy applications that don't use a dependency manager like Maven or Ivy. While all this information is beneficial for an architect or migration lead to understand the complexity of the modernization initiative, what about the migrators or the developers responsible for performing the actual changes on the source code? MTA also provides plugins for the most widespread IDEs on the market, like Visual Studio Code, Eclipse or IntelliJ. These plugins provide an integrated wave for developers to get guidance on the changes they need to make to the source code. We already have the project for the customer's application open in VS Code. By installing the MTA plugin, we get an additional view for configuring analysis. Note the configuration options are the same as in the web user experience. Once the configuration is ready, we can click on Run and the plugin will execute a local analysis and provide the results right on the IDE environment. Again, the analysis results show two occurrences of the issue from our custom rule in the Persistence Config class, like it did before on the web user experience. Clicking it brings us directly to the offending line in the source code. And the same details are offered to understand exactly what the problem is and what needs to be changed. Details will open side-by-side with the source code, highlighting the offending lines, providing all the required information for the migrators without having to move away from their IDE. The combined tools available in MTA provide a powerful way for an organization to manage, assess, and analyze its application portfolio. But it's only the beginning. We're working on multiple initiatives to widen the scope of MTA, allowing it to go beyond the assessment and analysis stages to fulfill our vision of providing value at every stage of the modernization process. Stay tuned for more features coming in MTA by visiting the product page available on the Red Hat Developer website. Thanks for watching.