Category: Uncategorized

Part 4 in the Uncovering Technical Debt Series from Intellyx, for vFunction. [Check out part 1 | 2 | 3 here.]

We’ve dug deep into our technology stacks, uncovering all of the legacy artifacts and monoliths that we could find from past incarnations of our organization. 

We’ve cataloged them, rebuilt them to modern coding standards, and decoupled their functionality into object-oriented, service-enabled, API-addressable microservices.

Now what? Are we modernized yet? 

Well, mostly. There are always some systems that just aren’t worth the time and attention to replace right now, even with intelligent automation and refactoring solutions.

Plus, we acquired one of our partner companies last year, and we haven’t had a chance to merge their catalog with our ordering system yet, so they are still sending us EDI dumps and faxes for urgent customer requests…

We’re never really done with continuous modernization

We’ve compared legacy modernization to the discipline of archaeology. But what happens once archaeologists finish their excavation and classification expeditions? Anthropologists can take over the work from here, interpreting societal trends and impacts even as the current culture continues to evolve and generate new artifacts. 

Similarly, discovering and eliminating uncovered technical debt isn’t a one-time modernization project, it’s a continuous expedition of reevaluation. Once an application is refactored, replatformed or rearchitected, it creates concentric ripples, exposing more dependencies and instances of technical debt across the extended ecosystem, including adjacent applications within the organization, third-party services and partner systems.

Mapping the as-is and to-be state of the codebase with discovery and assessment tools is useful for prioritizing the development teams’ targets for each project phase around business value, but business priorities will change along with the application suite. 

Development teams also get great utility from conducting modernization projects with the help of AI-driven code assessment and refactoring solutions like vFunction Code Copy, but they can realize even greater benefits by retaining the history of what worked (and didn’t work) to inform future transformations.

Not every modernization project works out equally well, but when the hard lessons of modernization feed back into the next assessment phase, this virtuous cycle can become part of the muscle memory of the organization, allowing mental energy to be spent on the most important choices that affect the long-term goals of the business.

Putting technical debt to rest: what to expect

No computer science college student or self-taught coder sets out to spend a career finding and fixing bugs in their code, much less someone else’s – but on average, developers spend at least 30 to 50 percent of their time on rework, rather than innovation and enablement of new features that are perceived to add business value.

Besides the perceived thanklessness of the effort, developers encounter morale-destroying toil when sifting through legacy code, which usually contains lots of class redundancies, recursive methods, poor documentation and a general lack of traceability, resulting in slow progress.

Continuous modernization offers a way out of this thankless job, by preventing technical debt from collecting during each assessment and refactoring phase. 

Here’s some levers teams are pulling for successful long-term improvements:

• Continuous assessment. The best performing initiatives are not just conducting initial assessments, they are continuously mapping, measuring and observing modernization efforts before, during, and after each refactoring run.
  
• FinOps practices basically bring financial concerns and tradeoffs to each modernization selection process or option. IT buying executives have been doing ROI analyses for vendor selection and capex computing investments for years. Now, savvy buyers are getting better cost justification for money spent on modernization, with real financial metrics for resources, employee and customer retention, and delivered customer value. 

• SLO objectives offer positive motivation for time-and-labor savings and incremental delivery of new services, in comparison to the negative contractual penalties enforced through SLA failures. Developers are incentivized to meet goals such as faster refactoring projects, faster automated deployments, and higher value updates – with fewer hitches and developer rework required.
  
• Qualitative business goals are equally as important to success. Better team morale improves productivity and employee retention rates, versus trying to replace high-quality people with new ones that could take months to get up to speed. Developers love working for agile enterprises, where they can test theories and ultimately help the application suite evolve faster in the future to meet changing customer needs.

Trending toward velocity and morale at Trend Micro

Trend Micro is considered a global leader in cloud workload security, with several successful products underneath the banner of its platform – but that didn’t mean their modernization journey started without major headaches. 

Much of their existing product suite, with more than 2 million lines of code and 10,000 independent Java classes, was built before secure API connections between cloud infrastructure and microservices were fully sussed out by the development market. Therefore, earlier customers were more inclined to trust on-premises installations and updates of vital virus, spam and spyware prevention software.

As the modern trends of SaaS-based vendors and cloud-based enterprise applications really hit stride over the last decade, Trend Micro started offering a re-hosted version of its suite under their CloudOne™ Platform banner.

Their initial lift-and-shift of one module’s code and data store to AWS offered some scalability and cost benefits due to elastic compute resources, but as the user base grew, it was becoming harder and harder for product dev teams to get a handle on inter-product dependencies that hindered future releases and updates to meet customer needs. Morale suffered as the replatforming took about a year.

Trend Micro turned to vFunction to identify and prioritize modernization of their most critical “Heartbeat” integration service – with more than 4000 Java classes that take in data from sensors, event feeds and data services across the product suite.

Then using vFunction for modernization, the team was able to visually understand code complexity, with an applied AI for identifying essential, interconnected and circular dependencies, deprecating dead code that would no longer add any actual value for customers going forward.

Through refactoring, they were able to decide which classes should be included as part of the new Heartbeat service, and which should be kept in a common library for shared use across other product modules in the future.

This modernization project took less than 3 months – a 4X speed improvement over the previous project, with successive update deployment times decreased by 90%. Best of all, morale on the team has improved by leaps and bounds.

The Intellyx Take

Continuous modernization offers enterprises a lasting bridge from the monolithic past to a microservices future, but with constant change at enterprise scale, the journeys across this bridge will never really end.

To get to the bottom of the biggest obstacles of modernizing our digital estates, we must first assess and prioritize code refactoring and application architecture efforts around resolving technical debt.

Then, our intrepid teams can venture forth, digging to unearth the artifacts and digital foundations of our organizations, transforming our applications into modular cloud native services, resetting the values of our shared culture, and adapting our architectures to meet the challenges of a global, distributed, hybrid IT future.

Can you dig?

©2022 Intellyx LLC. Intellyx retains editorial control of this document. At the time of writing, vFunction is an Intellyx customer. Image credit: Licensed from Alamy “2001: A Space Odyssey” movie still.

In today’s market environment, the ability to quickly take advantage of new technological capabilities is of paramount importance to a company’s ability to maintain or enhance its competitive position. That’s why for many businesses, the modernization of their legacy application portfolio has become not just a high priority but an existential necessity.

The problem such organizations face is that the legacy apps they depend on for some of their most essential business processes actually hinder their ability to keep pace with rapidly changing technological and marketplace conditions. Stefan Van Der Zijden, VP Analyst at Gartner, puts it this way:

“For many organizations, legacy systems are seen as holding back the business initiatives and business processes that rely on them… application leaders must look to application modernization to help remove the obstacles.”

The Importance of Application Modernization

Legacy apps are typically structured as monoliths, meaning that the codebase is organized as a single, non-modularized unit that has functional implementations and dependencies interwoven throughout. Updating such code to interoperate with the cloud-native systems and resources that dominate today’s technological landscape is difficult, time-consuming, risky, and costly.

To overcome this difficulty, organizations must modernize their legacy monolithic codebases to convert them into modern, cloud-native applications that can easily integrate into today’s technological environment. 

Most companies have not only recognized this fact but are acting on it – in a recent study conducted by Wakefield Research, 92% of respondents said their companies are either currently modernizing their legacy apps or are actively planning to do so.

Challenges of Application Modernization

Although application modernization is now considered by many companies to be essential, getting it right can be difficult. According to the Wakefield study, 79% of application modernization projects fail to achieve their goals. 

Application modernization efforts have historically been time-consuming and costly: the typical modernization project lasts 16 months and costs about $1.5 million—and more than a quarter of Wakefield survey respondents (27%) say their projects took two years or more. In a recent survey, 93% of respondents characterized their modernization experience as “extremely or somewhat challenging.”

Related: App Modernization Challenges That Keep CIOs Up at Night

App Modernization Pitfalls to Avoid

Let’s take a look at some common pitfalls that can, if you fail to avoid them, add your project to that 79% failure rate:

1. Inadequate Management Support

Buy-in by an organization’s executive management team is indispensable to the legacy app modernization success. In the Wakefield survey, both executives and architects cited a lack of “prioritization from management” as a major factor that “stopped modernization projects in their tracks.”

If a company’s executive management isn’t on board with the necessity for legacy app modernization and with the ROI such projects can be expected to yield, the budget, personnel, and other required resources either won’t be supplied at all or won’t be maintained at an adequate level. 

When changing marketplace conditions cause the organization to readjust its priorities, modernization projects can sometimes lose the management focus and budgetary support needed for success. To avoid that happening, you must be prepared to make and remake the case for the business utility and ROI of your modernization efforts as marketplace conditions continually evolve.

2. Failure to Adequately Address Cost Concerns

Nearly 50% of both executives and architects in the Wakefield study agreed that securing the needed budget and other resources is the most difficult step in implementing a modernization project. That’s typically because the executives who control the purse strings haven’t been given reliable information that convinces them that the return on the not-inconsiderable investment required for such projects will be great enough to justify the financial and business risks.

By conducting a  data-driven assessment of your legacy application estate, you can provide your organization’s management team with accurate, quantified data that makes the business case for investing the budgetary and other resources an app modernization project will require.

3. Misalignment Between Business and Technology Teams

The Wakefield study reports that 97% of survey respondents expected that someone in their organization would push back against modernization proposals. Such objections commonly occur when various stakeholders are not on the same page. Here are some typical reasons why that may occur:

• The risk seems too great—Because legacy app modernization involves significant changes to critical systems, there is a definite degree of risk attached to such efforts. In the absence of trustworthy information and specific, well-developed plans that mitigate the risk factors, business and IT stakeholders may be reluctant to accept the risks to business operations that a modernization project represents.
• Stakeholders fear large-scale change—When legacy applications are modernized, some associated workflows will usually also change. Well-established processes may be altered, and workers may need to be retrained or reassigned. Such developments introduce levels of uncertainty and instability that business stakeholders may be wary of.
• Stakeholders fear losing their role—The business process changes that arise from app modernization efforts may threaten the traditional roles of some stakeholders or seem to relegate their perspectives and concerns to a lower priority level.

To avoid having such concerns become sources of pushback, stakeholders should be presented with a well-developed, data-driven modernization plan that addresses their unique issues.

4. Failure to Accurately Set Expectations

In the Wakefield study, this was the #1 reason given by respondents who started modernization projects they didn’t complete. Areas of particular concern include unrealistic expectations relating to budget and schedule requirements and anticipated project results such as improvements in engineering velocity and application innovation. 

To overcome this obstacle you need to be able to supply stakeholders with accurate, quantified data regarding the complexity of the task and the timeframe and budget that will be required for completing it.

In addition, you must ensure that your modernization methodology can produce the results you promise. Companies often make the mistake of thinking that just moving an application to the cloud will provide an acceptable degree of modernization. That’s not the case. Such a migration (often called a “lift and shift”) retains all the disadvantages of the application’s monolithic architecture. 

True modernization only occurs when the app is not only migrated to the cloud but is refactored from a monolith to a microservices architecture. Only then will you fully reap the benefits that make a modernization project worthwhile.

5. Failure to Make Required Organizational Structure Changes

App modernization is far more than just a technical exercise. IBM puts it this way:

“A cultural transformation is also imperative. Organizational roles, business processes and IT skills must evolve and advance for your cloud migration and application modernization to be a success.”

According to Conway’s Law, the organizational structure of a software development group must align with the structure of the application they intend to produce. When that doesn’t happen, an app modernization project is headed for trouble. Software engineer Alex Kondov is adamant that “you can’t fight Conway’s Law,” and supports that declaration with this observation:

“Sadly, often a company’s structure may not support the system it wishes to create. Time and time again, when a company decides that it doesn’t apply to them they learn a hard lesson.”

6. Inadequate Skills or Training

A legacy app modernization project is a complex process that requires a level of expertise many companies don’t have in-house. So it’s no surprise that almost a third of respondents to the Wakefield survey cited a lack of worker skills or training as a key obstacle to success. 

Yet, in today’s job market, hiring and retaining highly skilled software developers can be a time-consuming and costly process. You can reduce this requirement by providing your development team with modernization tools that embody skills your developers may lack.

7. Lack of Intelligent Tools

In the Wakefield survey, this was the #1 reason cited by software architects for app modernization failures. The process of refactoring monolithic legacy apps to convert them to a cloud-native microservices architecture is a highly complex undertaking that may require unraveling tens of millions of lines of code to expose hidden functionalities and dependencies in the codebase. 

Doing this using an essentially manual approach may require many months or even years of developers’ time, and even then the risk of an unsatisfactory outcome is extraordinarily high. On the other hand, the use of a state-of-the-art, AI-enabled, automated modernization tool can speed up the process by orders of magnitude while all but eliminating the risk factors that plague manual efforts.

Related: The Easy Way to Transition from Monolithic to Microservices

App Modernization Starts with Using the Right AI Tech

Many companies attempt to modernize applications using general-purpose design, analysis, and performance monitoring tools. But these have proven to be inadequate for the task. 

What’s needed is a tool that’s specifically designed for modernization, with advanced AI capabilities that allow it to comprehensively analyze monolithic applications, reveal hidden dependencies and functional implementations, and benchmark the levels of technical debt, complexity, and modernization risk associated with each app. It should also be able to substantially automate the process of restructuring complex monolithic apps into microservices.

vFunction provides just such an automated, AI-empowered tool. The vFunction Assessment Hub measures the complexity, technical debt load, and modernization risk of each app. The vFunction Modernization Hub then automates about 90% of the process of refactoring monolithic codebases into microservices. 

To see first-hand how vFunction can help you avoid the pitfalls that have wrecked so many application modernization efforts, request a demo today.

For companies that depend on legacy applications for critical business processing, modernizing those apps to make them compatible with today’s technologically sophisticated cloud ecosystem is crucial. But because most legacy apps are monolithic, updating them can be a difficult, time-consuming, and risky process. 

A monolithic codebase is organized as a single unit that has function implementations and dependencies interwoven throughout. Because a change to one part of the code can generate unexpected side-effects in other parts of the codebase, any update has the potential to cause the app to fail in unpredictable ways.

Yet, if these legacy apps are to continue fulfilling their business-critical missions, they must have the flexibility and adaptability necessary for keeping pace with the ever-evolving requirements of a fast-changing marketplace and technological environment. What’s needed is a means of encapsulating any changes to the legacy code so that only the targeted function is affected.

The Strangler Fig Architecture pattern meets that need. It allows legacy apps to be safely updated by replacing each function with an independent microservice. This enables developers to incrementally modernize specific functions without impacting the operation of other portions of the app.

What is the Strangler Fig Pattern?

Martin Fowler, Chief Scientist at Thoughtworks, coined the term in 2004. He noticed that strangler fig seeds, which germinate in the upper branches of other trees, send down roots that surround and eventually strangle their host tree. In effect, the strangler fig kills the original tree and takes its place.

Fowler saw this as a metaphor for how a large, monolithic software application could be modernized by surrounding it with a new superstructure of microservices that, over time, strangles and replaces the original app. A microservice is a small, self-contained codebase that performs only one task and replaces a single function or service in the legacy app. It can be updated without affecting other parts of the app. 

As new microservices are added over time, they take over the functions of the original codebase one by one until the functionality of the legacy app is entirely replaced by microservices. At that point, the original app has been fully “strangled” and can be decommissioned.

Related: Migrating Monolithic Applications to Microservices Architecture

Why the Strangler Fig Pattern is Ideal for Application Modernization

Faced with the daunting prospect of replacing or rewriting their portfolio of legacy apps, some companies settle for simply migrating them, pretty much as-is, to the cloud. But though that approach may yield some benefits, it falls far short of true modernization. That’s because a monolithic codebase in the cloud is still monolithic, and retains all the detrimental characteristics of that architecture.

The Strangler Fig Pattern enables true legacy app modernization by allowing you to replace the functions of the original app one at a time without having to rewrite the entire app all at once. As key functions are re-implemented one by one as microservices, the app continues to function and can be fully transformed without ever going offline.

A key element of the strangler paradigm is the use of an interface layer, called a façade, between the original app and its microservices superstructure. All communications to and from the legacy app go through the façade, which includes feature flags that you can set to dynamically control whether the original code for a function or its microservice replacement is live.

This approach provides some major advantages:

1. Allows incremental updating

If you elect to entirely rewrite a legacy app, you can’t use the new system until the rewrite (and all testing) is complete. The strangler approach allows you to incrementally add features and capabilities without disrupting the operation of the app or taking it offline.

2. Enables quicker modernization

As each new microservice is added, the benefits it provides, such as increased adaptability, flexibility, scalability, and performance, take effect immediately. As IBM notes,

The great thing about applying this pattern is that it creates incremental value in a much faster timeframe than if you tried a “big bang” migration in which you update all the code of your application before you release any of the new functionality.

3. Minimizes risk

Any attempt to replace or upgrade a large monolithic app all at once will almost certainly introduce new bugs that can cause significant downtime once you bring the new codebase online. But, as Bob Reselman of Red Hat explains,

“Small failures are easier to remedy than large ones, hence the essential benefit of the Strangler pattern.”

Because the strangler approach incorporates changes in small steps, with each new microservice being thoroughly tested before going live with the app, downtime due to new bugs can be almost totally eliminated.

4. Allows you to choose the pace of modernization

Since the app is never taken offline, you can implement the modernization project at a pace that’s comfortable for your team (and budget).

5. Allows easy and seamless rollbacks

Rolling back a change that isn’t working correctly is easy. Each new microservice deployment can be quickly and cleanly reversed simply by setting feature flags appropriately.

6. Eliminates the need to maintain two separate codebases

New functions are implemented as microservices that surround the legacy codebase; the original app is never changed. Since any needed changes (including those that correct bugs in the legacy code) are made only to the microservices superstructure, the original codebase need not be separately maintained.

7. Enhances QA

Because microservices can be run in parallel with the original code for QA purposes, each change can be comprehensively tested in the app’s production environment before it goes live with the app.

How Refactoring With Strangler Fig Helps You Avoid Destructive Coding Anti-Patterns

As we’ve seen, the Strangler Fig Pattern provides an ideal template for modernizing legacy apps. However, some other widely used software design patterns yield far more negative results. These are called, appropriately, anti-patterns. Martin Fowler notes that the term was coined in 1995 by programmer Andrew Koenig, who described it this way:

“An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn’t one.”

According to Fowler, anti-patterns are extraordinarily dangerous because they initially fool developers into thinking they are appropriate solutions to common software coding problems, only to reveal their detrimental consequences later when the damage has been done. As software engineer Kealan Parr declares:

“In software, anti-pattern is a term that describes how NOT to solve recurring problems in your code. Anti-patterns are considered bad software design… They generally also add “technical debt” – which is code you have to come back and fix properly later.”

Parr lists some of the more common anti-patterns. They include:

Spaghetti Code

This anti-pattern is often encountered in monolithic legacy apps. The term describes a codebase that has little or no structure. There’s no modularization, and function implementations and dependencies are intermingled throughout the code, just like strands of spaghetti on a plate. As a result, the logical flow of the application is extremely difficult to understand. Parr calls it a maintenance nightmare:

“You will constantly break things, not understand the scope of your changes, or give any accurate estimates for your work as it’s impossible to foresee the countless issues that crop up when doing such archaeology/guesswork.”

Because of these characteristics, updating or adding features to spaghetti code is an extraordinarily difficult and risky process.

Golden Hammer

This anti-pattern derives its name from a quote attributed to Abraham Maslow:

“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

That’s a human tendency to which software developers are as prone as anyone else. When they have a high level of competence with, love for, or comfort with particular coding tools, languages, or architectures, they naturally seek to apply them across the board, even in situations where they are not the best options. The result can be highly detrimental—as Parr says, “Your whole program could end up taking a serious performance hit because you are trying to ram a square into a circle shape.”

Boat Anchor

Boat anchors do nothing but retard the progress of the vessel to which they are attached. And that’s exactly what the boat anchor anti-pattern does with software. The term describes code modules that developers insert into the codebase to implement functions not currently needed or used. They do so because they think those functions might be needed later.

This too, says Parr, is a maintenance nightmare. Developers who are new to the codebase, or who have not worked with it for some time, will have a hard time identifying boat anchor modules and figuring out whether they impact the logical flow of the program or are entirely superfluous. There’s a real possibility of your developers spending significant amounts of time and effort on understanding and debugging modules that literally do nothing.

Dead Code

This term describes code that, unlike boat anchors, implements functions that are not only used in the application but which may be called frequently from many different places in the codebase.

The problem is that it’s not clear what this code is doing or why it’s needed. Perhaps it had an important function at some point, but now the issues it was created to solve no longer exist. On the other hand, it could be crucial for handling infrequent edge or boundary conditions that current developers haven’t yet run into but eventually will. Because you can’t be sure why it’s there, you don’t dare to remove it. So, it remains in the codebase as a time-waster and generator of confusion for the developers who have to deal with it.

Proliferation of Code

This anti-pattern occurs when there are objects in the code that seem to exist only to invoke other more strategic objects. These are essentially useless “middleman” objects that provide no additional value, but only add an unnecessary level of abstraction, and therefore confusion, to the code. Such objects should be bypassed and removed to make the code more easily understandable.

God Object

This is sometimes called the “Swiss Army Knife” anti-pattern. It describes objects that are accessed by many other objects in the codebase for a multitude of different and often unrelated purposes. Such objects are problematic because they violate the Single Responsibility principle of coding, which says that every class, module, or function should do only one thing. According to software architect Thanh Le, they are “hard to unit test, debug and document” and can be a “maintenance nightmare.”

Strangler Fig to the Rescue!

Refactoring a legacy app according to the Strangler Fig Pattern will remove anti-patterns such as these from the codebase almost automatically. For example, Strangler Fig refactoring eliminates spaghetti code by re-implementing legacy app functions as a set of independent, single-task microservices that can be easily understood, maintained, and upgraded. 

Similarly, code that does too much is replaced by individual microservices with precisely specified, single-purpose functionality, while unneeded modules are not re-implemented at all. And Golden Hammer technology choices can be eliminated by implementing new microservices using a carefully chosen modern technology stack.

Best Practices to Implement the Strangler Fig Pattern

How can you maximize the benefits of the strangler fig paradigm in modernizing your legacy apps? Here are some best practices:

1. Automate the process using an AI-based modernization platform

As industry insider Oliver White has said,

“Large monolithic applications need an automated, data-driven way to identify potential service boundaries.”

Manual analysis of a monolithic codebase with millions of lines of code is a time-consuming, error-prone process. An automated, AI-based analysis platform can perform that task quickly, comprehensively, and at scale. Using static and dynamic analyses, it can assess the monolithic codebase for technical debt, complexity, and risk; reveal functional flows and dependencies; identify service domain boundaries; and quantify the amount of effort that will be needed to refactor the app.

That information will allow you to determine:

• the negative impact of your legacy apps’ technical debt on your ability to innovate
• the ROI that can be realized from modernizing some or all of your legacy apps
• which applications should be modernized and in what order
• which legacy app services should be re-implemented as microservices and which should not
• the functional scope of each microservice
• which functions are so similar or overlapping that they can be consolidated into a single microservice

Once the analysis phase is complete, a state-of-the-art modernization platform will be able to substantially automate the process of refactoring the monolithic code into microservices.

2. Pick the right starting point

For most companies, it’s not feasible—nor desirable—to modernize all their legacy apps at once. Instead, it’s best to start with those apps that have the greatest business value and which also have a high degree of technical debt. Then, for each app choose functions that have the highest impact on your business operations as the first to be re-implemented as microservices.

3. Pick the right ending point

It’s natural to want to replace all your legacy apps with microservices. But the costs of refactoring an entire legacy suite may exceed the benefits. In such cases, it might be best to continue using the original app for specific functions that are isolated, stable, and don’t require upgrading, while re-implementing as microservices any functions that must be easily upgradeable, or that interact directly with other systems or resources.

4. Follow an incremental, step-by-step process

The Strangler Fig Pattern provides its greatest benefits when it is applied incrementally, one microservice at a time. Avoid trying to modernize entire apps all at once. As one research paper succinctly advises:

“Start small and gradually evolve the system (baby steps).”

5. Implement new functionality only in microservices

When you begin the modernization process, you should freeze the legacy codebase and implement any new functionalities only through microservices. If you continue to make updates to the original app, you create two simultaneously evolving codebases, both of which must be supported, tested, and synchronized.

Related: Simplify Refactoring Monoliths to Microservices with AWS and vFunction

How AWS Migration Hub Refactor Spaces and vFunction Work Together

As an AWS Partner, vFunction provides an automated, AI-driven modernization platform that closely integrates with AWS Migration Hub Refactor Spaces to enable developers to quickly and safely transform complex monolithic Java applications into microservices and deploy them into AWS environments.

Refactor Spaces establishes, maintains, and manages the modernization environment, and orchestrates AWS services across accounts to facilitate the refactoring of legacy apps from monoliths to microservices. Refactor Spaces implements the Strangler Fig Pattern for the target application and allows developers to easily manage communication between services throughout the environment.

Developers begin the refactoring process by using vFunction to generate an automated, AI-based analysis that quantifies the complexity of monolithic legacy apps. Using both static and dynamic analyses, vFunction provides the detailed information regarding technical debt, complexity, and risk that’s required for developing a comprehensive refactoring plan that prioritizes which apps and services will be converted and in what order.

vFunction then automatically decomposes the monolithic apps into microservices. Using sophisticated, AI-driven static analysis, the vFunction platform analyzes architectural flows, classes, usage, memory, and resources to detect and expose critical business domain functions buried in the code and untangle complex dependency relationships.

See vFunction For Yourself

The vFunction platform is unique in its ability to make refactoring monolithic legacy apps into microservices as quick, easy, painless, and safe as possible. It easily handles codebases with tens of millions of lines of code, and can accelerate the modernization process by at least a factor of 15. If you’d like to see for yourself what it can do, please schedule a demo today.