Simplify Refactoring Monoliths to Microservices with AWS and vFunction

By Amit Bajaj, Sr. Partner Solutions Architect – AWS
By Amir Rapson, Founder and CTO – vFunction

vFunction

With estimates that 80% of the world’s business systems are still not cloud ready, executives have begun to mandate initiatives to modernize their legacy applications for the cloud.

These legacy applications are usually large monolithic systems with years or decades of accumulated technical debt, making them expensive and risky to scale, and weighing down an organization’s capability to innovate.

For simple use cases, some teams begin modernizing their legacy stack by rehosting applications on a cloud platform like Amazon Web Services (AWS). Though rehosting an application on AWS can bring immediate cost reductions, customers still have to manage and maintain these applications, which are often composed of tightly-coupled services which are difficult to change and face risks of downstream effects.

For complex and large legacy monoliths, enterprises can quickly run into a wall with rehosting alone. The more lines of code, classes, and interdependencies, the less value you get from lifting and shifting. To gain agility, these applications must be modularized and that means refactoring, rearchitecting, or even rewriting critical legacy applications to be cloud native.

In this post, we will share how AWS Migration Hub Refactor Spaces and vFunction help in the analysis of monolith applications, set priorities to extract the microservices, deploy the microservices in cloud-native AWS services, and route the user traffic with minimal effort.

vFunction is an AWS Partner which provides an artificial intelligence-driven platform for developers and architects that intelligently and automatically transforms complex monolithic Java applications into microservices, restoring engineering velocity and optimizing the benefits of the cloud.

Solution Overview

AWS Migration Hub Refactor Spaces is a modernization platform for developers working with applications that are not cloud native, or that are in the midst of their journeys to be cloud native.

Refactor Spaces provides the base architecture for incremental application refactoring to microservices on AWS, reducing the undifferentiated heavy lifting of building and operating AWS infrastructure for incremental or iterative refactoring. You can use Refactor Spaces to help reduce risk when evolving applications into microservices or extending existing applications with new features written in microservices.

Designed to eliminate the time, risk, and cost constraints of manually modernizing business applications, vFunction delivers a scalable, repeatable factory model purpose-built for cloud-native modernization.

Using the vFunction platform and Refactor Spaces together can solve the dual challenges of decomposing monolithic apps into microservices and then iteratively and safely staging, migrating, and deploying those microservice applications onto AWS environments. This lets enterprises breathe new life into their legacy applications, and refactor old code for new cloud environments.

Legacy system architects and developers start off with vFunction, which analyzes the complexity of monolithic apps using automation, artificial intelligence (AI), and patented analysis methods. This allows architects to automate and accelerate the rearchitecting and rewriting of their legacy Java applications into microservices.

Static Analysis to Calculate Technical Debt

Within minutes of installing vFunction, you can see the vFunction Base Report as shown in Figure 1 below. Using static analysis data, vFunction uses machine learning (ML) algorithms to calculate technical debt and quantify it. vFunction then enables architects and developers to begin building a business case for modernization.

Figure 1 – Base report.

The primary goal of the Base Report is to help stakeholders make an informed decision about which apps and services to prioritize for modernization.

In the vFunction platform, technical debt is calculated by looking at the complexity, calculated based on the amount of entangled interdependencies that reflect tight-coupling between business domains, and the risk, calculated by the length of class-dependency chains that increase the impact of downstream changes to any part of the system.

As a result, vFunction is able to determine the “cost of innovation,” which is a metric revealing how much per $1.00 invested is needed to manage your system’s technical debt, rather than innovating and building new functionality.

In the example above, the customer will have to spend $2.80 (x2.8) to achieve $1.00 towards innovation. The Post-Refactor metric shows that by tackling the top 10 High Debt Classes alone, this can be reduced to $2.20 (x2.2).

Dynamic Analysis to Determine Priorities

You can now look at Refactoring Effort analysis as shown in Figure 2 below. Adding to the static analysis performed earlier, vFunction performs patented dynamic analysis that leverages AI to build a representation of the effort it would take to refactor the application.

Figure 2 – Assessment output.

These parameters are based on vFunction analysis utilizing clustering algorithms and graph theory to measure complexity scores based on:

• Class exclusivity
• Resource exclusivity
• Service topology
• Infra percentage
• Extracted percentage

Class Exclusivity

Class exclusivity refers to the percentage of classes exclusive to specific services. A high class exclusivity score means that most services contain whole domains, indicating more bounded contexts and fewer interdependencies.

Resource Exclusivity

Resource exclusivity refers to the percentage of application resources–like Java beans, database tables, sockets, and files–that are exclusive to the services. Similar to class exclusivity, a high resource exclusivity score hints the domain is encapsulated within the service, and there are limited constraints for extracting the service.

Service Topology

Service topology refers to the complexity of service-to-service calls required for the application to run. In this example, the customer wants a lower service topology score, which indicates less chatter and communication overhead between services. In some applications, it’s required to add more complexity to the communication between services in order to increase class and resource exclusivity. This is a decision architects will be required to make in many complex applications.

Infra Percentage Score

Infra percentage refers to the number of overall classes vFunction recommends be put in a common library. A high infra percentage score indicates a low amount of infra classes found in common libraries, which helps avoid tight coupling between services and limits technical debt.

Extracted Percentage

Extracted percentage refers to the percentage of classes that can be safely removed from the monolith based on the target refactoring plan. A high percentage here indicates it will be possible to eliminate any remainder of the original monolithic application.

Using these scored metrics above, companies can enter the Analysis pane (aka vFunction Studio) of the vFunction platform dashboard to view the exact services identified, with drill-down capabilities to better review the analysis.

Figure 3 – Analysis pane.

In the image above, you can see a sample application called Order Management System (OMS). This image shows a visual representation of the services and classes in this application. The size of the circle is determined by the number of classes called in each service.

Green circles represent services with high class exclusivity (over 67%), and blue circles represent services with lower class exclusivity (between 33%-67%). The higher the class exclusivity, the easier it will be to extract it into a loosely coupled microservice architecture with reduced interdependencies.

Further interaction with the platform reveals interdependencies between beans, synchronization objects, database tables, database transactions, and more. You can drill down into a specific service to see entry points, call trees, and classes that were found by the dynamic analysis or by the static analysis, tracked resources, and dead code classes.

The vFunction platform allows you to refine the boundaries of the services and determine the architecture, while automatically recalculating the metrics of the designed architecture. Next, you can iteratively extract any service.

Figure 4 – Service extraction.

The image above shows vFunction extraction configuration of your updated single microservice to a target platform and source repository. The platform generates human-readable JSON files that includes all of the information to create the service, with the extracted code from the original monolith using vFunction’s Code-Copy utility, which can then run in vFunction’s terminal or integrated development environment (IDE).

In the next section, we’ll look at how to take your extracted services and use Refactor Spaces to set up and manage the infrastructure to test, stage, and deploy the new version of your service.

Deployment to AWS

Now that we’ve reviewed the vFunction platform experience, let’s look at the sample application architecture after service extraction and the beginning of modernization.

The OMS example referenced above is a legacy Spring Framework application running on Apache Tomcat 9 and deployed on an Amazon Elastic Compute Cloud (Amazon EC2) instance. In the image below, we see a system architecture in which the original monolithic OMS application is running on Tomcat 9 (bottom right).

Figure 5 – OMS system architecture.

Using Refactor Spaces, you can employ the familiar Strangler Fig pattern on the OMS application, decomposing it into microservices with vFunction and deployed to AWS (top right).

From a previously monolithic architecture, we have split the OMS into multiple services deployed with Kubernetes on Amazon Elastic Kubernetes Service (Amazon EKS) using NGINX for exposing the REST API.

We created a proxy for the OMS app, services, and routes. In this case, there are two services: one for the original monolith, and the other representing the microservice extracted by vFunction and now running on Amazon EKS with NGINX Ingress.

This produces default routes to the service that represents the monolith, along with the URI path that routes API calls to the other controller service.

Figure 6 – Amazon EKS view.

AWS Migration Hub Refactor Spaces created multi-account environment automatically, orchestrating AWS services across accounts to create a refactor environment for incrementally evolving an application. It reduced the complexity of refactoring the monolith by simplifying management of existing apps and microservices as a single application with flexible routing control, isolation, and centralized management.

Refactor Spaces also generated an Amazon API Gateway that routes the API calls to a Network Load Balancer and AWS Transit Gateway. Some traffic continues to go to the monolith running on Amazon EC2, where we have the product and inventory data. Other traffic goes through NGINX—with the same URL but a different route—to the other controller in Amazon ECS.

With the above loosely coupled microservices architecture, customers gain accelerated feature releases, rapid experimentation, independent scaling, more resiliency, higher agility, and quick customer feedback loops. These benefits directly contribute to business outcomes.

Conclusion

Enterprises that have been challenged by having to modernize highly complex legacy applications within their business landscape can jump-start their journey to cloud-native architecture in a de-risked, methodical, and iterative way.

With the vFunction platform, architects and developer can assess, analyze, and extract services from the monolith. With AWS Migration Hub Refactor Spaces, they can route and manage traffic with minimal effort. Both capabilities together enable them to employ the Strangler Fig pattern to decompose a traditional application into services, and route requests to two different destinations: the original monolith, and the newly decomposed microservices.

If this seems like a good fit for your modernization initiative, contact vFunction to learn more about its products in a personal demo session.

.

.

vFunction – AWS Partner Spotlight

vFunction is an AWS Partner which provides an artificial intelligence-driven platform for developers and architects.

Contact vFunction | Partner Overview | AWS Marketplace

*Already worked with vFunction? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.