IBM Cloud Satellite: Build faster. Securely. Anywhere. Read more

Transform monolithic applications to microservices with IBM Mono2Micro

Before you begin

This tutorial is part of the Introduction to IBM Mono2Micro series.

In this series, learn about the key features of IBM Mono2Micro and how to use them to transform monolithic Java applications into microservices.

Introducing Mono2Micro

Application refactoring refers to the process of partitioning legacy applications into microservices, preserving the original semantics of the applications. Refactoring is not easy. Architects examine code, deployment artifacts, test cases, and available documentations to recommend microservices. This process is manual, ad-hoc, subjective, time-consuming, and error-prone. Many refactoring projects get abandoned after spending a significant amount of time and resource. IBM Mono2Micro, the revolutionary application transformer, automates the process of application refactoring using AI.

Early experimentations with Mono2Micro have generated tremendous enthusiasm and demonstrated significant value. For large legacy monolithic applications containing few hundreds to few thousands of classes, Mono2Micro generated sound microservice recommendations, verified by SMEs, within a very short time span in a completely non-invasive way. For some of these monolithic applications, manual refactoring takes quite some time. The manual refactoring results, when available, are compared against those obtained from Mono2Micro.

At IBM Research, we developed novel AI techniques using machine learning and deep learning for analyzing application artifacts, such as invocation graphs, data dependencies (static), and runtime traces (dynamic). Mono2Micro’s refactoring ability hinges on these techniques, based on static and dynamic analysis of applications.

The first beta version of Mono2Micro, announced on May 6, 2020, focused on automatically generating two categories of microservice recommendations (suggested groupings of classes): business logic seams-based and natural seams-based. As of July 7, 2020, an ‘enhanced beta’ is available, providing the advanced features of customization of microservice recommendations and automatic code generation. With these features, Mono2Micro should be able to assist in successfully refactoring large and complex Java Enterprise monolithic applications in weeks, in comparison to manual or other approaches, which often take months if not years.

Using Mono2Micro

To refactor Java applications using Mono2Micro, you need to perform the following steps:

  • Instrument the source code by inserting simple print statements for tracing function entries and exits using a Mono2Micro utility.
  • Build and deploy the instrumented versions of the applications in pre-production but representative environments using the build and deployment tools that you use.
  • Execute tests corresponding to the various business use cases on the instrumented versions of the monolithic applications.
  • Provide the generated trace files along with a few JSON metadata files generated during the instrumentation and business case execution phases to Mono2Micro’s AI component.

Visual representation of steps needed to refactor Java applications using Mono2Micro, with outcome-based recommendations and groupings

Figure 1. Overview of Mono2Micro

The AI component of Mono2Micro will automatically provide you the microservice recommendations by applying its novel machine learning algorithms. Mono2Micro also generates reports about the details of recommended microservices along with deep invocation analyses of their interactions. The invocation analysis reports of the recommended microservices are of special interest to application developers, which can be used for guidance to evaluate and implement the microservice recommendations. You can view the microservice recommendations and the generated reports in the easy-to-use and intuitive Mono2Micro GUI.

Business logic seams-based grouping

Mono2Micro analyzes runtime traces corresponding to the executions of various business use cases. The traces convey the details of the flow of control through the classes implementing specific business uses cases, including the invocation sequences and frequency of interactions. Machine learning and deep learning techniques are used on the runtime traces to capture causalities, functional similarities, and other temporal relations among classes and their methods. These temporal relations derived from runtime traces are used to arrive at the grouping of classes according to business logic seams, as shown in Figure 1. Figure 2 shows such a grouping for a sample application, where the circles represent classes, and groupings of classes are color-coded. The directed edges between classes represent runtime invocations.

Screenshot of business logic seams-based groupings in Mono2Micro for a sample application

Figure 2. Business logic seams-based groupings for a sample application

Natural seams-based grouping

Mono2Micro further augments the business logic seams-based grouping with inter-class data dependency analysis. Mono2Micro’s algorithm iteratively merges relevant groupings of classes having data dependencies and produces natural seams-based groupings, as shown in Figure 1. The natural seams-based groupings closely approximate the stateless and share-nothing microservice architecture, which minimizes the need for any rewrites for refactoring. For the same application’s business logic seams-based grouping, depicted in Figure 2, a natural seams-based grouping is shown in Figure 3.

Screenshot of natural seams-based groupings in Mono2Micro for a sample application

Figure 3. Natural seams-based groupings for a sample application

Meet in the middle grouping

While natural seams-based groupings of classes seem to be ideal for microservice architecture, for most existing monolithic applications, such a strategy may fail to provide expected benefits from the resultant refactoring because most of the legacy applications were not designed keeping microservices in mind. Also most of their constituent classes typically have dependency relationships among themselves, which will result in one or two microservices containing practically all the important classes of the monolithic applications.

We expect architects and developers to arrive at ideal groupings of classes using their knowledge of applications by starting their journey from the natural seams-based grouping and drifting somewhat towards the business logic seams-based grouping, or vice versa. The ‘meet in the middle’-based groupings of classes will be arrived at an iterative fashion consulting the detailed microservice recommendations and the invocation analysis reports.

The enhanced Mono2Micro GUI will provide the mechanisms necessary so that the SMEs can adjust and fine-tune groupings of classes to arrive at the desired microservice recommendations.

Automatic code generation

In monolithic applications, non-primitive objects are passed freely by references, and all the required class definitions are freely available everywhere in the source code. In refactored monolithic applications, inter-microservice parameters cannot be passed by references. Most of the microservices may not even compile on their own since they may contain method parameters, return values of non-primitive types, and their dependencies, which are actually defined in other microservices. To address these problems in manual or other modes of refactoring, SMEs have to develop a significant amount of plumbing code (code for externalizing data, for example). Developers often copy all of the class definitions in all of the microservices, which will necessitate the build and redeployment of all the microservices, even if one of the class definitions change.

Mono2Micro addresses all of these issues in a unique way by automatically generating a bulk of the code needed for realizing groups of classes as microservices. Mono2Micro will completely take care of the cross-microservice object references automatically in a very efficient fashion. Mono2Micro’s code generation mechanism also does not copy class methods or constructor definitions in the implemented microservices.

Next Steps

Learn more about Mono2Micro and modernizing applications: