vFunction Guides Enterprises Toward Continuous Modernization

For companies making the transition from monolith to microservices, the move is neither finite nor all-encompassing. Rather, of the millions of lines of code they may have, some may be separated out to become microservices, while some may be moved as they are to containers or virtual machines (VMs), while others still may stay exactly as they are — all of it part of a process defined by cloud native modernization platform vFunction as “continuous modernization.”

vFunction, which emerged from stealth earlier this year after spending several years developing its scalable, repeatable factory model to transform monolithic Java applications into microservices, has recently launched several new features to help companies find their way along this continuum of modernization. Specifically, this latest release sees the launch of the vFunction Application Transformation Engine (vAXE), the expanded vFunction Modernization Platform (vMP), and the ability to analyze database dependency to help with the transition to microservices.

Bob Quillin, chief ecosystem officer at vFunction, explained that since their launch, they have worked with customers at various stages of the transition process and have since developed tools to focus on those various stages.

“Early on, we saw some people who were doing proof of concepts with us for some smaller applications,” Quillin said. “As we got into some of their larger environments, we saw and started getting access to some really big applications, where the pain really was. That’s probably, in many ways, a sweet spot for us, in that there are people who have been working on an application for a while, and they’re struggling to extract it. They just don’t have the tools.”

When The New Stack first spoke with vFunction earlier this year, the company offered up the example of a monolithic application with 100,000 lines of code and 250 classes, but now the focus has shifted to include the idea of “megaliths”, which vFunction defines as applications of over 10 million lines of code and over 10,000 Java classes.

The expanded vMP, for example, provides a single pane of glass to not only help organizations manage and track their migration process but to also provide an automatic assessment of which parts of an application are most suitable for modernization. Companies with megaliths are not simply converting their entire application estate into microservices in one fell swoop, and vFunction’s vAXE helps by first performing a dynamic analysis “via a passive JVM agent to accurately analyze flows, classes, usage, memory, and resources” alongside a static byte code analysis. Using these analyses, vMP then shows a rating regarding the complexity of refactoring certain sections of code, and code can be marked for refactoring, retention/retirement, re-platforming, or rewriting.

“We’re not advocating that you need to refactor 100% of your applications,” explained vFunction CEO and co-founder Moti Rafalin. “It doesn’t necessarily make sense, and that’s not the purpose of what we’re trying to do. We want to assist customers to make the right decision for these applications, and based on the information that we provide them, they can make that decision, and then flag those applications that are not a fit for refactoring.”

Part of the problem for some of these companies, explained Rafalin, is that the megalith is so large and complex that, as they try to modernize their codebase, they can’t keep pace.

“They’ve been working for two years on modernizing one of those large monoliths, and we asked them ‘What has been the progress so far?’ and they said ‘We’ve extracted about 30% of the code into services, but over these two years, the monolith has grown by 40%, so we’re actually in a worse position than where we started,'” he said.

This, said Quillin, is where the idea of continuous modernization enters the picture.

“A theme we’re starting to see, kind of along the lines of continuous integration and continuous delivery, is continuous modernization, where I’m constantly monitoring technical debt, making sure I have no dead code, that I have good test coverage, and preventing the next monolith from happening,” he said. “Monitoring your technical debt, making sure your current applications don’t become monoliths in the future — that’s the next phase as people move forward, and we see it kind of as an adjunct to a lot of the DevOps processes.”