 Hello everyone! Welcome to this demo for the Migration Toolkit for Application 7. Today we will be showcasing the new features of our tool while onboarding a classic Tomcat application on OpenShift. The user experience in MTA 7 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. As the portfolio goes through the different processes available in the tool, surface information will be stored individually in each application profile. That includes metrics such as risk level, the effort required to migrate, precise data about issues that need to be solved, and the application's technology stack. One of the key challenges when dealing with large portfolios is to figure out a way to group applications together, and then determine different migration strategies for each group. MTA 7 provides multiple ways of classifying applications. The simplest way is through business services that represent the different business verticals, divisions, or teams that an organization might have. For example, let's focus on retail applications. Another powerful feature that helps with application classification is an extensible tagging model that lets you classify applications in multiple dimensions. MTA comes standard with a wide set of curated categories and tags, but users can add more to model any concept that could be meaningful in the context of their organization and application landscape. Here we've added tags that represent the application technology stack, like Java, Tomcat, and some spring components, with an additional custom tag representing the usage of a custom corporate configuration library. Make note of this, as configuration is one of the key concerns when onboarding an application into the cloud. When dealing with applications at scale, a more sophisticated way of grouping applications may be required to manage large portfolios effectively. Archetypes simplify the grouping process by automatically classifying applications based on their tag taxonomy. At the same time, applications associated with an archetype inherit some of their features, such as additional tags or assessment data. Let's create a new archetype that covers all traditional spring applications in the organization so we can centralize their management. Applications that match all the criteria tags will be automatically associated with the archetype. Archetype tags are the tags that will be inherited by applications just by being associated with the current archetype. This is a way to store metadata about applications at scale. In this case, we will associate a dedicated tag for the framework and information about the configuration model and runtime, which would be Tomcat for this type of application. Archetypes often refer to corporate architectures or frameworks that are maintained by a specific department or team inside the organization. You can also include the relevant stakeholders associated with an archetype. As you can see, the archetype has already been associated with two applications automatically. One of these applications should be our customer's application. The application profile effectively reveals that the customer's application has been associated to the summer framework archetype. Given the association, the application has inherited the archetype tags we previously defined for the summer framework archetype. The assessment module provides a high-level overview of a given application or archetype through the use of questionnaires. The tool ships with a containerization questionnaire included, with more curated questionnaires coming in future releases. MTA-7 also makes it possible to author custom questionnaires by using a YAML syntax. Returning to our previous example and considering that both archetypes and applications can be assessed, we'll move forward by assessing the summer framework archetype we created earlier. So, whatever findings we make during the assessment are applied to all the associated applications in the portfolio. The first step will be to select a questionnaire from the list. Let's go with the defaults and stick to the containerization questionnaire that's included with MTA-7. You can think of a questionnaire as the script for having a meaningful conversation. Because the conversation will potentially involve multiple stakeholders, it's important to document them in case it's necessary to reach out later to ask for clarifications. The containerization questionnaire aims 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 associated with this archetype from running in containers or may require an adjustment. Let's get forward to see what risks were found. 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 take a look at them by scrolling down to the list of risks. It looks like the archetype defines a discovery mechanism that is not cloud-friendly. That makes sense because associated applications are deployed in a traditional platform and access a database through a static IP. As stated before, the archetype uses a custom configuration library that happens to load configurations from multiple paths on the file system. That is definitely an anti-pattern for cloud deployments, so we will need to find where that library is used in associated applications and replace it with a more cloud-friendly approach. Knowing that changes are required in the source code to adapt applications associated to this archetype, we can use the refactor strategy. We believe that only the configuration library needs to be replaced and should require minimal effort. Since this archetype has been identified as essential for the business, criticality and priority should be set to the max. We can now save to check or adjust it later on if we want to. It's clear that we need to dig deeper into applications associated with the summer framework archetype to identify everywhere the custom configuration library is being used and what needs to be done to remove it. For that, we can use the analysis module available in MTA. MTA 7 includes a new analysis engine that will provide support for multiple languages in subsequent releases. This engine is capable of static code analysis against both source code and binaries. Analysis provides insights on the dependencies and technology stack of applications and identifies potential issues that might prevent an application from running on a target platform. In order to demonstrate this feature, let's get back to our customer's application and run an analysis against it. The first step on the analysis wizard is to define the analysis mode. The most comprehensive one, source and dependencies, retrieves the application's 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. 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. 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 interest 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 anti-patterns 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 a configuration summary for the analysis. By clicking Run, the analysis will be scheduled and begin shortly. MTA 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 start digging into the results. As stated before, analysis in MTA provides insights on several aspects of an application. The first and most straightforward one is to identify the technology stack and associate it to the application profile as tags so that the information can be used later to automatically assign archetypes across the portfolio. The analysis also gathers precise data about the dependencies used by the application. If we're only interested in the dependencies of a single application from the application profile, clicking on Dependencies on the Details tab would bring us to the dependencies view with filters already applied and displaying all dependencies for our application. MTA 7 now provides portfolio-wide insights about dependencies. If we remove the single application filter, we can see dependencies that are being used across the entire portfolio. Clicking on a dependency will give us the list of applications using it, including which version is being used in each. This detail view also includes information about the type of relationship and a link to Maven Central in case the dependency is an open-source library. But probably the most important insight that an analysis provides is the list of issues. Issues are anti-patterns found in applications that might prevent them from running on a particular platform. As with dependencies, MTA 7 now allows for managing issues globally instead of on a per-application basis as it did before, enabling users to identify trends across the entire application portfolio. For example, let's take a look at issues that were found in applications that used the Summer Framework archetype. The list includes direct access to the file system and the usage of hard-coded IPs, which is aligned with our findings during the assessment. It appears that the custom rule we specified before was also triggered. To look on the issue, we get more information about it, including code snippets, links to external information, and the list of affected applications. As expected, the list of affected applications includes our customer's application. Clicking on it provides the list of affected files, including the number of incidents and the expected effort. In MTA, 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. Clicking on a file leads to precise insights for where the issue can be found in the source code, along with detailed information on how to solve it. Each occurrence of an issue in a file will be recorded, providing code highlights for the first five. While all this information is beneficial for an architect or migration lead to 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 way for the 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 a 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.