Monoliths to Microservices: 4 Modernization Best Practices

When it comes to refactoring monolithic applications into microservices, most engineering teams have no idea where to start. Additionally, a recent survey revealed that 79% of modernization projects fail, at an average cost of $1.5 million and 16 months of work.

In other articles, we discussed the necessity of developing competencies for assessing your application landscape in a data-driven way to help you prioritize your first big steps. Factors like technical debt accumulation, cost of innovation and ownership, complexity and risk are important to understand before blindly embarking on a modernization project.

Event storming exercises, domain-driven design (DDD), the Strangler Fig Pattern and others are all helpful concepts to follow here, but what do you as an architect or developer actually do to refactor a monolithic application into microservices?

There is a large spectrum of best practices for getting the job done, and in this post, we look at some specific actions for intelligently decomposing your monolith into microservices.

These actions include identifying service domains, merging two services into one, renaming services to something more accurate and removing services or classes as candidates for microservice extraction. The best part: Instead of trying to do any of this manually, we’ll be using artificial intelligence (AI) plus automation to achieve our objectives.

Best Practice #1: Automate the Identification of Services and Domains

Surveys have shown that the days of manually analyzing a monolith using sticky notes on whiteboards take too long, cost too much and rarely end in success. Which architect or developer in your team has the time and ability to stop what they’re doing to review millions of lines of code and tens of thousands of classes by hand? Large monolithic applications need an automated, data-driven way to identify potential service boundaries.

The Real-World Approach

Let’s select a readily available, real-world application as the platform in which we’ll explore these best practices. As a tutorial example for Java developers, Oracle offers a medical records (MedRec) application — also known as the Avitek Medical Records application, which is a traditional monolith using WebLogic and Java EE.

Using vFunction, we will initiate a “learning” phase using dynamic analysis, static analysis and machine learning based on the call tree and system flows to identify ideal service domains.

In Image 1, we see a services graph in which services are shown as spheres of different sizes and colors, as well as lines (edges) connecting them. Each sphere represents a service that vFunction has automatically identified as related to a specific domain. These services are named and detailed on the right side of the screen.

The size of the sphere represents the number of classes contained within the service. The colors represent the level of class “exclusivity” within each service, referring to the percentage of classes that exist only within that service, as opposed to classes shared across multiple services.

Red represents low exclusivity, blue medium exclusivity and green high exclusivity. Higher class exclusivity indicates better boundaries between services, fewer interdependencies and less code duplication. Taken together, these traits indicate that it will be less complex to refactor highly-exclusive services into microservices.

The solid lines here represent common resources that are shared across the services (Image 2). Common resources include things like beans, synchronization objects, read-only DB transactions and tables, read-write DB transactions and tables, websockets, files and embedded files. The dashed lines represent method calls between the services (Image 3).

The black sphere in the middle represents classes still in the monolith, which contains classes and resources that are not specific to any particular domain, and thus have not been selected as candidates for extraction.

By using automation and AI to analyze and expose new service boundaries previously contained in the black box of the monolith, you are now able to begin manipulating services inside of a suggested reference architecture that has cleared the way to make better decisions based on data-driven analysis.

Best Practice #2: Consolidate Functionality and Avoid Duplication

When everything was in the monolith, your visibility was somewhat limited. If you’re able to expose the suggested service boundaries, you can begin to make decisions and test design concepts — for example, identifying overlapping functionality in multiple services.

The Real-World Approach

When does it make sense to consolidate disparate services with similar functionality into a single microservice? The most basic example is that, as an architect, you may see an opportunity to combine two services that appear to overlap — and we can identify these services based on the class names and level of class exclusivity.

In the services graph (Image 4), we see two similar chat services outlined with a white ring: PatientChatWebSocket and PhysicianChatWebSocket. We can see that the physician chat service (red) has 0% dynamic exclusivity and that the patient chat service (blue) has slightly higher exclusivity at 33%.

Neither of these services is using any shared resources, which indicates that we can merge these into a single service without entangling anything by our actions.

By merging two similar services, you are able to consolidate duplicate functionality as well as increase the exclusivity of classes in the newly merged service (Image 5). As we’re using vFunction Platform in this example, everything needed to logically bind these services is taken care of — classes, entry points and resources are intelligently updated.

Merging services is as simple as dragging and dropping one service onto the other, and after vFunction Platform recalculates the analysis of this action, we see that the sphere is now green, with a dynamic exclusivity of 75% (Image 6). This indicates that the newly-merged service is less interconnected at the class level and gives us the opportunity to extract this service with less complexity.

Best Practice #3: Create Accurate and Meaningful Names for Services

We all know that naming things is hard. When dealing with monolithic services, we can really only use the class names to figure out what is going on. With this information alone, it’s difficult to accurately identify which classes and functionality may belong to a particular domain.

The Real-World Approach

In our example, vFunction has automatically derived service domain names from the class names on the right side of screen in Image 7. As an architect, you need to be able to rename services according to your preferences and requirements.

Let’s now go back to the two chat services we merged in the last section. Whereas previously we had a service for both the patient and physician chat, we now have a single service that represents both profiles, so the name PatientChatWebSocket is no longer accurate, and may cause misunderstandings for other developers working on this service in the future. We can decide to select a better name, such as ChatService (Image 7).

In Image 8, we can see another service named JaxRSRecordFacadeBroker (+2). The (+2) part here indicates that we have entry points belonging to multiple classes. You may find this name unnecessarily descriptive, so you can change it simply to RecordBroker.

By renaming services in a more accurate and meaningful way, you can ensure that your engineering team can quickly identify and work with future microservices in a straightforward way.

Best Practice #4: Identify Functionality That Shouldn’t Be a Separate Microservice

What qualities suggest that functionality previously contained in a monolith deserves to be a microservice? Not everything should become a microservice, so when would you want to remove a service as a candidate for separation and extraction?

Well, you may decide that some services don’t actually belong in a separate domain, for example, a filter class that simply filters messages. Because this isn’t exclusive to any particular service, you can decide to move it to a common library or another service in the future.

The Real-World Approach

When removing functionality as a candidate for future extraction as a microservice, you are deciding not to treat this class as an individual entry point for receiving traffic. Let’s look at the AuthenticatingAdministrationController service (Image 9), which is a simple controller class.

In Image 9, we can see that the selected class has low exclusivity by the red color, and also that it is a very small service, containing only one dynamic class, one static class and no resources. You can decide that this should not be a separate service by itself and remove it by dragging and dropping it onto the black sphere in the middle (Image 10).

👁 Image

By relocating this class back to the monolith, we have decided that this particular functionality does not meet the requirements to become an individual microservice.

In this post, we demonstrated some of the best practices that architects and developers can follow to make refactoring a monolithic application into bounded contexts and accurate domains for future microservice extraction.

By using the vFunction Platform, much of the heavy lifting and manual efforts have been automated using AI and data-driven analysis. This ensures that architects and development teams can spend time focusing on refining a reference architecture based on intelligent suggestions, instead of spending thousands of hours manually analyzing small chunks of code without the appropriate “big picture” context to be successful.