vFunction decomposes monolithic Java applications and refactors them into useable microservices for modern clouds. Users cannot leverage these monolithic applications in modern cloud services and infrastructure, be it Kubernetes, or anything else, without refactoring.
The Challenge of Refactoring
If users lift and shift, they can shut down their datacenter and move to the public cloud. However, that company will not get any savings because those applications that have been moved are still a monolith.
For example, if users re-platform, take the monoliths, and put them in a container, they will benefit on the DevOps side. However, they will not get any of the micro-services cost savings. For that, users need to refactor. Up until recently, there has been no application that works completely.
The problem is, refactoring is incredibly hard to do manually; it takes days of manual extraction, testing, and figuring out what belongs to what. However, it is necessary to modernize those apps to gain value from the cloud. It’s a sticky situation.
The vFunction Solution
The disappointment of lift and shift is something that is growing. vFunction’s cloud-native organizational platform offers developers and architects the ability to intelligently and automatically transform complex monolithic Java applications into microservices.
More technically, it does thematic analysis, applied data science, graph theory, and automation to transform Java applications from monolith to microservices in a scalable, repeatable factoring model.
Once vFunction began deploying its platform, it saw hundreds and sometimes thousands of Java monoliths per company. Visibility is needed in the modernization process. vFunction has platform dashboards, and monitoring included so that users can see through that modernization and manage all of those microservices.
vFunction is a developer’s tool, it is not a black box where users feed information, and something comes out. Users must maintain the microservices once they have been extracted.
Deployment and the Secret Sauce
When vFunction deploys, it goes through a learning and assessment phase, or dynamic analysis. Users deploy vFunction in production or preproduction, and then it does tests to expose the functionality.
Dynamic analysis tries to identify actual user flows in the application. It wants to identify services that correlate to specific domains within the application. Those can be identified by monitoring the actual use of the application through the logic to the UI.
This is where vFunction’s secret sauce is; it samples the thread one hundred times per second and extracts the full code. It tries to correlate what it finds and optimizes the entry point to each of those microservices associated with existing domains using many algorithms and much data science.
vFunction replaces manual processing with algorithms and complements it with static analysis of the binary to complete things it doesn’t see in the dynamic analysis. It relies on this to identify flows in the application. Users ideally want also to do regression or acceptance tests to gain the best coverage of the application. Synthesis of the dynamic and static analysis flows to the platform where the platform does all of the crunching and the data science to show the possible services it recommends extracting.
Interactivity
vFunction is an interactive platform, and architects can make changes, merge services, split services further, drill into them. It allows users to design the microservices users want to extract.
With the push of a button, it creates a service specification file with all of the information required to generate that microservice based on the original code. Then vFunction has an automation engine that scans the original code. Users need access to the source code and the relevant artifacts to create those microservices designed efficiently through the vFunction platform.
The resulting services are domain services, so they have all of the logic for delivering a precise user flow within the application. For example, an ordering management system application in the retail industry function would identify the inventory services, the ordering service, the shipping service for users to decide what they want to extract.
Benefits
Firstly, vFunction will automatically identify dead code, and with a push of a button, can take it out from specific services. The services that the platform helps users create are the most efficient ones, with minimal context required for those services.
Secondly, users don’t have the long manual discovery process. Around ten days are needed to figure out an application manually. The developer has to check, go back and figure out how it fits into the puzzle—a total ballpark figure of 15 days end-to-end for one microservice.
With vFunction, you need maybe one or two developers to work on a platform. The cost savings are significant, the time to market is substantial, the risk reduction is vast. Users can also go back and forth with vFunction and revert those microservices and can do it many times in a matter of hours.
The function output is still in Java, but users can sometimes take it to Spring Boot. The idea is to have a straightforward project with APIs, which users can then start upgrading and changing.
The whole process also reduces significant risk, which becomes even more significant if you have hundreds of applications.
Conclusion
vFunction can optimize, mitigate security issues, and improve application function by modernizing the code. With the billions of monolithic Java applications companies are struggling to get value out of, vFunction seems like a good start.
