Category: Uncategorized

Navigating the path through the complexities of technical debt, software architecture refactoring, and application modernization is a major challenge facing architects and development teams today. According to National Geographic, navigation is both an art and a science. The earliest forms of navigation used known landmarks to arrive at a destination. It wasn’t until sailors learned how to use the stars that they ventured onto the open seas. However, navigation also required correcting courses to avoid obstacles that could sink a ship.

While safely getting from point A to point B may have been navigation’s original goal, speed was also a concern. Reaching a destination during prime hunting season was essential for a reliable food supply. Navigators were continuously assessing routes to minimize delays. When navigation tools, such as sextants and compasses, became more reliable, expectations grew. Arriving within a particular time window wasn’t enough. Cargo was expected to arrive undamaged despite rough seas. Passengers traveled the fastest, most reliable routes. 

In the world of software development, the analogy of navigation finds its modern counterpart in continuous modernization. Similar to ancient navigators adapting to new tools, today’s software developers employ cutting-edge technologies for constant refactoring and refinement. Continuous modernization involves the ongoing process of updating software to match the evolving tech landscape. 

Just as sailors correct their course to avoid obstacles, developers identify and address challenges in real-time. By embracing continuous modernization, businesses ensure their software not only meets but exceeds user expectations, adapting swiftly to market demands and emerging technologies. This agile approach allows organizations to maintain a competitive edge and deliver seamless user experiences in the ever-changing digital realm.

Navigating a Path to Architectural Excellence

For software organizations, navigating a path to excellence means using human creativity and imagination alongside appropriate modernization tools for exceptional results. Just as early navigators watched their environment for changes, software architects must be able to see what is happening in real time to make adjustments before a disruption occurs. They must continuously assess their location to avoid drifting off course and creating unnecessary delays.

Unlike navigators of old, today’s software architects have access to architectural observability tools for end-to-end visibility. Navigators had to rely on knowledge passed from one navigator to another. Sailors learned the safest and fastest routes from centuries of shared experiences. But modern observability tools allow software engineers to condense years of monitoring into minutes. They do not have to wait months or years to correct structural flaws.

Related: Creating a Technical Debt Roadmap for Modernization

Organizations looking to modernize their applications must combine correction methods with observability to maintain a successful path of continuous modernization. These companies must tap into creativity and imagination to sustain a culture that successfully manages the journey of software evolution.

Why Visibility Matters in Software Architecture Excellence 

Navigational visibility means watching where you are going. It’s about using the next measuring point for determining direction. Suppose the destination is the mouth of the Amazon. Navigators can assume that as long as they keep the shore in sight, they will reach the Atlantic Ocean. What they can’t determine is how soon or how safely they will arrive. Without measuring the distance between a boat and the shore at frequent intervals, navigators do not know if they are on course.

The Science of Visibility

Navigating software modernization is no different. Development teams need to see what their code is doing. For example, teams have typically used the following tools to monitor code performance: 

• Metrics. Teams can gather data on memory usage and requests per second to assess resource utilization.
• Logs. Logs record events and errors that occur during execution. Teams can use logs to assess performance or identify anomalies.
• Traces. Teams can use tracking tools to trace requests and responses as they move through a system to locate where execution errors occur.

These monitoring tools make visibility possible; however, the value of collected data depends on the extent and frequency of the measurements. That’s where the art of visibility enters the process.

The Art of Visibility 

How often a sailor measured a ship’s relative position depended on the navigator. Longer intervals between measurements increased the chances of drifting off course. Shorter periods between calculations could result in unnecessary course corrections that impact transit time. Finding the perfect balance was an art.

Today, 86% of international software development companies use an agile methodology, with the majority following a Scrum framework. That means updated software could be deployed every 30 days since the maximum sprint length is one calendar month. The official Scrum guidelines recommend incremental software releases at least every two months.

Although every sprint may not result in a release, DevOps should monitor each increment. For many organizations, that target may be unreasonable if sprints occur every two weeks. They may not have the resources to support such a pipeline. However, extending the time between measurements may allow the software to veer off course. Software teams must find the right balance.

Charting a Course for Software Excellence

Navigating an agile process is the same as navigating a boat down the Amazon. It’s striking the right balance to maintain a design without delaying releases. Waiting until development is complete to assess a codebase is like using the shoreline to navigate the Amazon. You’ll reach the Atlantic eventually, but the condition of the boat, passengers, and crew is questionable.

Incremental measurements make successfully navigating software modernization possible. Agile methodologies divide a project into intervals that enable organizations to deliver updates efficiently with less drifting and technical debt. The process ensures continuous improvement and is the cornerstone of continuous modernization strategies. 

Why Architectural Observability Is Essential

Architectural observability is the ability to analyze an application statically and dynamically and understand its architecture, observe drift, and find and fix architectural technical debt.

Success depends on the monitoring tools that enable architectural visibility, and the right tools make navigating modernization more reliable by looking at visibility data in context. Architectural observability makes managing architectural technical debt a science—based on data.

The Art of Observability

Observability tools give architects and engineers more time to explore unique and innovative solutions. They provide better control over a system’s architecture as it evolves. Deploying architectural observability solutions allows software teams to experience the art of observability.

When software teams operate reactively, they have little time to look beyond the immediate problem. Their response can often lead to more technical debt. Like a becalmed sailing ship, they cannot progress. Their modernization journey stalls.

Carefully monitoring observability results enables organizations to address architectural drift before it becomes a problem. They can break down the tasks into segments that can be accomplished incrementally with less impact on the modernization process. Development teams can incorporate architectural changes into their normal workflow, minimizing disruptions.

Related: How Continuous Modernization Can Address Architectural Drift

The art of architectural observability involves learning how to use the right tools. Selecting and deploying these tools frees architects and engineers from mundane monitoring tasks. They have time to discover solutions and devise implementation plans that deliver results without disruption.

When architectural drift is allowed to continue, the build-up of technical debt eventually grinds developer productivity to a halt, and the resulting corrections must disrupt development because they must be deployed quickly. Those disruptions can lead to frustrations. When architectural corrections are integrated into the continuous modernization process, technical debt is managed and workflows are not interrupted.

The Science of Architectural Observability

Navigation tools have moved far beyond the sextant. Today, navigators rely on global positioning systems (GPS) to determine their relative position. These satellite-based systems use contextual data to update routes when unexpected disruptions occur, and they recalibrate directions when an object moves off course.

Software architecture observability tools provide architects and engineers with similar capabilities. They can analyze application architecture, identify possible concerns, and monitor technical debt. They can even suggest an appropriate path to success.

The right architectural observability tools continuously monitor system architecture for the following:

• Sources of technical debt such as cross-domain pollution, database relationship violations, and high debt classes.
• Deviations from baseline, such as new services or classes, dead code, or exclusivity changes.
• Anomalies that weaken architectural integrity.

Architectural observability delivers contextual data and actual “to-do” lists in real-time for a more comprehensive analysis and a better understanding of system performance. Architects can proactively address technical debt and architectural drift using more robust information. They can assess the impact and respond proactively rather than devise a reactive solution to an immediate problem. Much like early navigators, teams that make reactive decisions cannot assess the ramifications to the overall journey.

Unlock Software Excellence with Architectural Observability

Companies can continue to operate with the tools equivalent to a navigator’s sextant and compass. They can wait years for their collective experiences to lend accurate observability. Alternatively, they can use the equivalent of a GPS system to guide their modernization efforts, and they can take advantage of advanced architectural observability tools to ensure a continuous modernization process that delivers software excellence.

vFunction’s Architectural Observability Manager is a solution that incorporates the art and science of navigating a continuous modernization path. Businesses can consistently achieve software excellence by relying on AI-driven tools that offer a reliable path forward. To see how we can help you navigate your modernization journey, request a demo.

Introduction

You have picked a new destination for your applications that will bring efficiency, ease of maintenance, and upgraded technology, but you are finding that you have to continuously tack due to headwinds such as:

• Budget shortages
• Required upgrades
• Safety and security patches
• Priority maintenance and enhancement requests
• Conflicting business priorities
• New applications for new revenue streams, or new customer acquisitions.

You can’t get where you want to go in a direct, straight line because of all the conflicting interests and priorities for application maintenance, enhancement, and replacement.

It is not at all clear how you will achieve your goals of modernization, paying down technical debt, and addressing architectural debt, despite the clear business value of doing so.

The first thing to do is identify a target state to codify the strategic business value of the modernization program. The target describes the future state of the IT systems post modernization and ties it to strategic business value such as increased revenue, improved cost efficiency, or supporting the launch of a new product.

If you’re sailing a boat, your target would be a landmark on the other side of the river. If reaching your target means you are sailing into the wind (i.e., you have headwinds), the only way to make progress is to tack across the wind from side to side and make progress incrementally.

An IT practice called “Managed Evolution”¹ describes in detail how to continuously make progress toward the business value achieved through modernization.

As shown in Figure 1, the central principle of managed evolution is to evaluate each proposed modification to the system in the context of whether or not it helps you to move you closer to the desired system state. The framework allows you to assess the incremental business value of doing so, and therefore help decide whether investments are strategic or not.

It is of course impossible to align every modification to achieving the target, resulting in the zig-zag journey shown in the diagram. It’s like sailing into the wind – you can see your destination, but you can’t head straight toward it. You have to make progress sideways and incrementally.

Modularity to Reduce Complexity

One strategy for implementing the managed evolution approach is to use abstract interfaces to modularize legacy system functionality so that it can be updated without impacting the user-facing part of the application.

For example, wrapping a legacy system function using a REST API transforms the legacy data format into a standard JSON payload for web and mobile applications. Once this is in place you can upgrade the back-end technology without disturbing the API consumers.

Once you have the abstract interfaces in place, the next step is to break out common components into individual services, such as microservices for example.

Recently there’s been a lot of debate about whether monoliths are better than microservices, but this really misses the main point, which is the advantage of modularity. Many studies over the past decade or so have clearly shown that modular systems are easier to maintain and change.

Of course, there’s no single right answer for every application, but in thinking about microservices it’s important to keep in mind how they align to the principles of modular systems.

The first step in moving from a monolith to a modular services architecture is to incrementally break out common functions into independent components, as illustrated in Figure 2.

For example, break out a common function or domain such as a customer lookup or price calculation, deploy it independently, and access it from multiple applications using a REST API.

Once you break out and modularize a critical mass of services, you can start constructing entire applications out of them, effectively replacing the monolith.

The most challenging part can be figuring out the modularity of the interfaces. Practices such as Domain Driven Design (DDD) and Service Oriented Architecture (SOA) can help.

Another very good reason for moving to modular systems is that services can be implemented using different programming languages and software systems. Some might be implemented using Java and deployed using a Java EE application server. Others might be implemented and deployed using .NET.

Modular systems are easier to maintain and evolve and are easier to update and deliver to production. Modular systems also improve developer productivity by dividing up the work.

Staying on Track

Even more important than defining the target state is documenting the current state and finding a way to measure progress from the current state to the target state, daily if possible.

Measuring progress frequently helps the modernization project stay on track and get a handle on how much architectural debt is being paid off. Paying down architectural technical debt is like paying off credit card debt – it has incremental benefits. The more you modularize your systems, for example, the easier they are to develop, maintain, and change.

So, this would be a good measure of progress for example to measure how many independent services have been created? How many abstract interfaces? What is the reuse count of independent services (i.e., how many applications consume them)?

First, get a good picture of what’s out there. Then decide on a methodology or architectural framework to guide the journey from current to target (and by the way, it’s always a target because it moves).

Adjustments to the target state should be made regularly as the modernization work progresses. Documents and designs must be kept up to date during the project to reflect changes that inevitably occur. Ensure that the implementation aligns to the architecture, and update continuously. 

How does vFunction Help?

vFunction analyzes the architecture of your Java and .NET applications to identify domains and score your technical debt. It also identifies candidates for modules or domains that can be broken out and hosted as independent, shareable services.

vFunction can help set the architecture baseline for the current state and uses architectural observability to detect drift, prescribe fixes, and send alerts to architects about architectural events and other actions on high debt modifications. In other words, it helps track progress toward the target state goal and regularly scans and reports on the evolving architecture.

vFunction also helps achieve modularization by refactoring monoliths into microservices and generating abstract APIs for them.

The Intellyx Take

Application modernization is a continuous journey across a jagged line of organizational headwinds. It’s more of a process than a technology, but the right technology can help a lot.

vFunction provides a unique set of tools to help architects understand where they are starting from in the journey, how far they have progressed (and whether course corrections are needed), and to automate the work around modularization, decomposition, and service abstraction.

The capabilities of these tools promise to be extremely valuable to anyone undertaking the continuous modernization zig-zag journey.

Copyright © Intellyx LLC. vFunction is an Intellyx customer. Intellyx retains final editorial control of this article. No AI was used to write this article.

Image by Tim Green, Creative Commons license

^[1]See:  https://www.amazon.com/Managed-Evolution-Strategy-Information-Systems/dp/3642016324

In today’s fast-evolving technological and marketplace environments, the software applications that companies depend on must be able to quickly adapt to the demands of an ever-changing competitive landscape. But as existing features are modified and new ones added, an app’s codebase inevitably becomes more complex, making it increasingly difficult to understand, maintain, and upgrade. How can developers ensure that their apps remain flexible and adaptable even as changes are incorporated over time? They can do so by applying the principle of continuous refactoring.

As Techopedia notes, the purpose of refactoring is to improve properties such as readability, complexity, maintainability, and extensibility. When these factors are regularly enhanced through continuous refactoring, apps can maintain their utility well into the future.

But, as management guru Peter Drucker famously said, “You can’t improve what you don’t measure.” That’s what architectural observability is all about: ensuring that developers have the ability to see and quantitatively measure the conditions they need to address through the critical process of  continuous refactoring.

Why Modernization Requires Continuous Refactoring

Application modernization can be described as the process of restructuring old apps to eliminate technical debt and seamlessly integrate them into today’s cloud-centric technological ecosystem. Technical debt is typically a major stumbling block in such integrations because it, by definition, involves “sub-optimal design or implementation solutions that yield a benefit in the short term but make changes more costly or even impossible in the medium to long term.” In other words, apps afflicted with significant amounts of technical debt can be extremely difficult to upgrade to meet new technical or competitive requirements.

The modernization process typically begins by refactoring legacy apps from a monolithic architecture (in which the codebase is organized as a single unit that has functional implementations and dependencies interwoven throughout) to a cloud-native distributed microservices architecture. But application modernization doesn’t stop there.

Because the cloud environment is constantly evolving, with technological innovations being introduced practically every day, new technical debt, and the decrease in adaptability that comes with it, begins to accumulate in an app from the moment it’s migrated to the cloud. That’s why modernization can’t be a one-and-done deal—rather, it’s a never-ending, iterative process. Martin Lavigne, R&D Lead at Trend Micro, puts it this way:

“Continuous modernization is a critical best practice to proactively manage technical debt and track architectural drift.”

Since refactoring is fundamental to the modernization process, continuous modernization necessarily involves continuous refactoring to remove technical debt and ensure that apps maintain their adaptability and utility over time.

The Impact of Architectural Drift

As Lavigne’s statement indicates, tracking and addressing architectural drift is a critical element of a successful application modernization program. That’s because architectural drift is one of the main sources of the new technical debt that migrated apps constantly accumulate as they operate and are updated in the cloud. So, what is architectural drift and why is it so important for ongoing application modernization?

Related: Benefits of Adopting a Continuous Modernization Approach

Apps are typically designed or modernized according to a coherent architectural plan. But as new requirements arise in the operating environment, quick changes are often made in an unregulated or ad hoc manner to meet immediate needs. 

As a result, the codebase and architecture begins to evolve in directions that are not consistent with the original architectural design, and technical debt, in the form of anti-patterns such as dead code, spaghetti code, class entanglements, and hidden dependencies, may grow. To make matters worse, such changes are frequently documented sparsely—if at all.

This inevitable accumulation of architectural technical debt over time is what architectural drift is all about. And it can be deadly. In an article that describes architectural technical debt as “a silent killer for business” Jason Bloomberg, Managing Partner at Intellyx, makes this comprehensive declaration:

“One of the most critical risks facing organizations today is architectural technical debt. The best way to keep such debt from building up over time is to adopt Continuous Modernization as an essential best practice. By measuring and managing architectural technical debt, software engineering teams can catch architectural drift early and target modernization efforts more precisely and efficiently.”

But that’s not an easy task. Architectural drift is difficult to identify and even harder to fix. The problem is that application architects have traditionally lacked the observability required for understanding, tracking, measuring, and managing architectural technical debt as it develops and grows over time. And, to paraphrase Peter Drucker’s maxim, you can’t improve what you can’t observe.

The Basics  of Observability 

Observability is an engineering term of art that refers to the ability to understand the internal states of a system by examining its outputs. A system or application is considered observable if its current state can be inferred based on the information provided by what are known as the three pillars of observability: event logs, metrics, and traces.

• Event logs are records that track specific events chronologically. They are critical for characterizing the app’s behavior over time.
• Metrics are quantitative measurements, such as CPU utilization, request response times, and error rates, that provide numerical data about the performance and health of the app.
• Traces record the end-to-end flow of transactions through the app. They allow developers and architects to understand the interactions and dependencies between various components of the app.

Observability is crucial for the initial refactoring of monolithic legacy apps into microservices. A fundamental goal in the refactoring process is to maintain functional parity between the original application and its post-refactoring implementation in the cloud. That is, the refactored app should initially (before any updates or corrections are incorporated) function identically with the original monolith in all feasible operational scenarios.

Achieving functional parity depends on architects having deep insight into the performance and functioning of the original monolithic codebase. A high degree of observability is required to ensure that all functionalities and use cases of the original app are identified and appropriately addressed in the refactored implementation.

Related: How Continuous Modernization Can Address Architectural Drift

Once an app has been initially refactored and integrated into the cloud environment, observability becomes even more important. An app that’s been restructured to a cloud-native, microservice-based, distributed architecture is typically composed of many different components and services that, by design, function and scale independently of one another. 

Although such apps are almost uniformly easier to understand conceptually than were their monolithic precursors, they also are more topologically and operationally complex and require an even greater depth of observability for developers to fully understand how the system is functioning.

Applying Observability in Continuous Refactoring

Architectural observability is a key element of the continuous refactoring process. It allows architects to identify, monitor, and fix application architecture anomalies on an iterative basis before they grow into bigger problems. The fundamental principle governing observability in app modernization is that comprehensive monitoring must be performed throughout the refactoring process so that developers have an in-depth view of the behavior and performance of their apps at every step.

Achieving comprehensive architectural observability involves a combination of static analyses and real-time operational monitoring that enables development teams to gain deep insights into their application’s structure, behavior, and performance at every stage of refactoring. Key performance indicators (KPIs) are defined and tracked, and monitored load and stress testing is conducted to identify potential bottlenecks and scaling challenges.

Architectural drift is detected by first establishing an initial architectural baseline that describes how the app functions in normal operation. Monitoring then continues as changes are detected in the architecture, allowing developers to proactively detect and correct issues that can lead to architectural drift. The baseline is reset and the monitoring procedure repeated at each step in the continuous refactoring process.

Tools for Observability in Continuous Refactoring

Attaining a high degree of observability requires the use of appropriate monitoring tools. Such tools must provide deep domain-driven observability through sophisticated static analyses, as well as dynamic tracking of process flows and dependency interactions during actual user activity or test scenarios.

A good observability tool will be capable of baselining, monitoring, and alerting on architectural drift issues such as:

1. Dead Code: code that is accessible but no longer used by any current user flows in production.
2. Service Creep: services are added, deleted, or modified in ways that no longer align with the established architectural design.
3. Common Classes: commonly used functions are not all collected into a shared class library to reduce duplicate code and dependencies.
4. Service Exclusivity: failure to ensure that each microservice has its own defined scope and is not unnecessarily interdependent with other services.
5. High-Debt Classes: classes that have a high degree of technical debt due to elevated levels of complexity, functional issues or bugs, and difficulties in maintainability or adaptability.

A good example of an advanced observability tool that performs these functions at a high level is the vFunction Architectural Observability Platform. This solution allows architects to manage, monitor, and fix architectural drift issues on an iterative, continuous basis. Not only does it identify and track architectural anomalies, but it notifies developers and architects of them in real-time through common alert systems such as email, Slack, or the vFunction Notifications Center.If you’d like to know more about how a state-of-the-art tool can provide the architectural observability needed to incorporate continuous refactoring into your application modernization process, we can help. Contact vFunction today to see how.

In a recent survey of corporate IT leaders, 87% of respondents said that modernizing their critical legacy apps is a top priority. When it comes to developing an effective approach to the complex and difficult task of application modernization, a great place to start is by taking an in-depth look at a Strangler Fig Pattern example and how it can help with modernization efforts. 

Companies must focus on increasing their agility in order to meet the constantly changing demands of today’s marketplace. For most, doing so will involve upgrading their business-critical legacy software applications to function effectively in today’s cloud-based technological ecosystem. 

The problem with most legacy apps is that they are extremely difficult to update, extend, and maintain because of their monolithic architecture. A monolithic codebase is organized as a single unit with functions and dependencies interwoven throughout. Because of those often-hidden dependencies, a change to any part of the codebase may have unintended and unforeseen effects elsewhere in the code, potentially causing the app to fail.

But when legacy apps are modernized and deployed using the Strangler Fig Pattern, technical debt  can be remediated more quickly, efficiently, and safely than can be achieved using more traditional approaches.

What a Strangler Fig Pattern Example Can Teach Us

The Strangler Fig Pattern is a key concept for understanding how to address technical debt and safely modernize large monolithic Java and .NET apps. But what, exactly, is the Strangler Fig Pattern?

The term was coined in 2004 by Martin Fowler. He noticed that the seeds of the strangler fig tree germinate in the upper branches of another tree. As the strangler fig tree’s roots work their way to the ground, they surround the host tree and, over time, expand so much that they strangle and eventually kill it. At that point, the strangler fig tree has, in effect, replaced the original tree.

Fowler saw this pattern as a good model for the way large monolithic apps can be safely modernized by creating a set of microservices that surround the app, replacing its functions one-by-one until the original app is entirely superseded by the framework of microservices built around it. That’s the Strangler Fig Pattern in application modernization.

Related: The Strangler Architecture Pattern for Modernization

To get a feel for how this pattern works in practice, we want to dig into a real-world Strangler Fig Pattern example that will illustrate the process and help us understand the results that can be expected. We’ll start by looking more closely at why the Strangler Fig Pattern is so crucial for the app modernization process. Then we’ll examine a case study that shows how one corporation applied the strangler fig concept in modernizing its large portfolio of business-critical legacy apps.

Why App Modernization Is So Difficult

The goal in reducing technical debt and modernizing legacy applications is to restructure them from their original stand-alone, monolithic design—a design that can integrate only partially and with great difficulty into the modern cloud ecosystem—into a more modular cloud-native microservices architecture that functions naturally in that environment.

Microservices are designed to be small, loosely coupled, self-contained, and autonomous. Each one implements a single business function and can be developed, deployed, executed, and scaled independently of the others. Because of that loose coupling between functions, a microservices-based app can be updated relatively quickly, easily, and safely.

In contrast, the very structure of the typical legacy Java app injects a high degree of complexity into the modernization process. The functions and services of a monolithic codebase are usually so tightly coupled and interdependent (and, in many cases, so inadequately documented) that unraveling execution paths and dependencies to gain a clear understanding of the code’s functionality and run-time behavior can be a complex and error-prone process. This inherent observability issue makes identifying and implementing appropriate technical remediation fixes extremely difficult, time-consuming, and risky.

The key issue in modernization is to restructure a legacy app’s architecture to give it cloud-native capabilities while ensuring that the functionality of the original app is faithfully maintained.

How the Strangler Fig Pattern Facilitates Application Modernization

Because of the difficulties an architect will typically encounter in developing a comprehensive understanding of a monolithic codebase’s behavior in all possible runtime scenarios, any attempt to completely replace or restructure a large legacy app all at once will almost certainly introduce bugs that can cause significant and often hard-to-trace operational disruptions.

The Strangler Fig Pattern allows the restructuring to be done step by step, one function at a time. At each step a single domain or microservice is implemented and fully tested before it is incorporated into the app. The testing is accomplished by running the new domain or microservice in parallel with the original app in the production environment to ensure that both always respond identically to the same inputs.

The testing process is facilitated by the use of an interface layer called a façade. All external requests to the application go through the façade. Initially, before any microservices are incorporated, the façade simply passes requests directly to the original app. But once a new microservice is implemented and verified through testing, the façade directs all requests concerning that function to the microservice rather than to the old app.

Because each domain or microservice is exhaustively tested in normal operations before it replaces the equivalent original function, there’s typically no need to ever bring the app offline to do a cutover to the new version, and the chances of unexpected disruptions due to the restructuring process are all but eliminated. Nor is there any need to maintain two different versions of the app since the original code is never changed but is simply replaced, function by function, one at a time, by microservices.

Eventually, all the legacy app’s functions are replaced by the equivalent fully tested microservices. At that point the Strangler Fig Pattern has done its job—the old app has been entirely displaced and can be retired.

Now, let’s look at a practical Strangler Fig Pattern example.

A Strangler Fig Pattern Case Study

Many large and well-known companies, such as Netflix, Google, IBM, and Microsoft, use the Strangler Fig Pattern in their application modernization efforts. A global leader in Software Security with more than a half million customers around the world and $2 billion in revenues, is also on that list.

One of their most business-critical software systems was in desperate need of upgrading. This system, which had a combined 2 million lines of code and 10,000 highly interdependent Java classes, was originally implemented on-premises. 

Parts of it were successfully migrated to the Amazon Web Services (AWS) cloud using a lift-and-shift process. This provided some improvements in compute resource usage. But because the codebase was still monolithic in its architecture, with deep interdependencies across multiple modules, the system experienced significant challenges in terms of performance, scaling, development velocity, and deployment speed.

Because their key security suite was still overwhelmingly monolithic even after it was rehosted to AWS, it was increasingly causing integration and upgrade problems, leading them to mount a major modernization effort.

The company’s modernization team elected to work with an external partner to implement a Strangler Fig approach using an advanced, state-of-the-art, AI-based modernization platform. They started by using the modernization platform to conduct static and dynamic analyses to identify complex circular or unnecessary dependencies in the monolithic code and determine appropriate service domain boundaries. They then employed iterative refactoring, using the Strangler Fig Pattern, to eliminate those dependencies and create relevant microservices.

Related: Simplify Refactoring Monoliths to Microservices with AWS and vFunction

The process of refactoring the monolith to create microservices, which would have taken more than a year if done manually, was completed in less than three months. And the time to deploy an update to AWS was reduced from nearly an entire day to one hour.

Unleashing the Potential of the Strangler Fig Pattern

The benefits that can be gained in our Strangler Fig pattern example are available to any company that’s faced with the imperative of fixing technical debt and updating their legacy apps to keep pace with the requirements of today’s ever-changing marketplace and technological environments. Although modernizing a suite of monolithic apps is a highly complex and challenging undertaking, companies can make the process far less daunting by doing three things:

1. Use architectural observability and the Strangler Fig Pattern to iteratively refactor your monolithic code into microservices.
2. Work with a modernization partner organization that has deep experience and expertise in transforming monolithic Java apps into a microservices implementation.
3. Rather than performing modernization tasks manually, make use of the advanced, AI-based tools that are now available.

If you’d like to explore how implementing the Strangler Fig Pattern can boost your company’s app modernization efforts, a good place to start is where our case study customer started. After making little progress on their own for over a year, they teamed with vFunction for expert guidance and assistance in the modernization process. 

They used vFunction’s state-of-the-art, AI-based continuous modernization platform to deploy architectural observability, substantially automating essential tasks, such as performing static and dynamic analyses to identify domains and dependencies in monolithic code, determining appropriate service domain boundaries, and refactoring monolithic code functions to microservices.

To get started with unleashing the power of the Strangler Fig Pattern in your company’s technical debt and modernization efforts, contact us today to request a Strangler Fig Pattern demo.

For a growing number of companies today, app modernization is a high priority. They’re attempting to update their IT infrastructure and reduce costs by moving software applications out of their on-premises data centers and into the cloud. According to CloudZero, more than two-thirds already have some or all of their IT estate in the cloud, with 39% running at least half of their workloads there.

But for many, this effort hasn’t worked out as they hoped. According to a report from Fortinet entitled, “The Bi-Directional Cloud Highway,” 74% of companies have migrated apps to the cloud but then moved them back again. Some of those return trips were planned, but many constituted an implicit admission that the initial transfer to the cloud failed to produce the expected results.

So, what went wrong?

In many cases, companies were disappointed because they didn’t obtain the financial savings they anticipated. CloudZero notes that six out of ten survey respondents report that their cloud costs are higher than expected, while 53% say they have yet to see any substantial ROI from their cloud investment. Respondents in another survey estimate that their organizations have wasted 32% of the funds they’ve spent on the cloud.

But it doesn’t have to be that way. Companies that develop and execute a well-targeted strategic plan for their cloud efforts can reap significant savings by modernizing their legacy apps to give them cloud-native capabilities.

In this article, we want to identify some of the most significant features of such a strategy.

How App Modernization Helps Reduce Costs

In the typical company today, engineers spend about 33% of their time dealing with technical debt. That term refers to the amount of unplanned work an IT organization must devote to supporting apps that, due to their outdated design or implementation, have become extremely difficult to maintain or adapt to meet new requirements. Continually investing scarce resources into keeping such apps running is a common but costly practice.

Related: How Much Does it Cost to Maintain Legacy Software Systems?

On the other hand, modernizing legacy applications to give them cloud-native capabilities can produce significant savings in and of itself. Intel quotes a recent study as declaring that when companies reduce their technical debt load by modernizing their legacy app portfolio, they realize immediate savings that amount, on average, to 32% of their IT budget. And according to IBM, companies that implement an effective app modernization program can expect benefits such as:

• 15% – 35% year-over-year infrastructure savings
• 30% – 50% lower app maintenance and operational costs
• 74% lower costs for hardware, software, and staff
• 14% increase in annual revenue

Getting App Modernization Right

Many companies fail to reap the expected benefits from their app modernization efforts because they confuse modernization with simple migration. They assume that by simply migrating their legacy apps from a data center environment to the cloud, without making any substantial changes to the app design or implementation, they achieve a significant degree of modernization. That’s not the case.

Legacy apps typically are monolithic in structure, meaning that the codebase is a single unit that has functional implementations and dependencies interwoven throughout. The very design of such apps creates a high level of technical debt because a change to any function can have unexpected effects elsewhere in the codebase, potentially causing the app to fail. Because of that inherent technical debt, monolithic apps are by nature very difficult to maintain and update.

When a monolithic app is transferred as-is to the cloud (a process called “lift and shift”) it carries its technical debt with it: all the factors that made the app difficult to maintain and adapt in the data center continue to do so in the cloud. And although it still needs the same CPU, memory, and storage resources it did in the data center, a monolithic app cannot efficiently access those resources in the cloud. All this can have a huge negative impact on cloud costs. In an article on the lift and shift methodology, IBM puts it this way:

“An application that’s only partially optimized for the cloud environment may never realize the potential savings of cloud and may actually cost more to run on the cloud in the long run.”

In reality, a monolith is the most expensive type of app to run in the cloud. It’s only when monolithic apps are truly modernized, by refactoring them to a cloud-native microservices architecture, that the full benefits of the cloud are obtained.

Reducing Cloud Costs

Once legacy apps have been refactored to have cloud-native capabilities, further steps can be taken to reduce cloud costs even more. Cloud cost efficiency is built on the fact that cloud-native services are inherently elastic, scalable, and adaptive. You can minimize your costs by fine-tuning your cloud operation to take full advantage of these characteristics. Here are some ways to do that:

Reduce Operational Costs

Because of the cloud’s superior elasticity, cloud-native resources, including newly modernized legacy apps, can scale instantly and automatically based on demand. That allows you to rightsize your compute resources to fit your utilization requirements. Here are some ways to do that:

1. Attribute your costs. To make sound decisions regarding forecasts, budgets, and cost optimization, you must understand how your IT costs are allocated across your organization. Identifying which functional areas contribute most to your overall cost structure allows you to sharply focus your cost reduction efforts.
2. Inventory your compute resource needs. This enables you to determine the instance size and type you need for each workload based on historic usage patterns, and select the lowest-cost options that meet your requirements.
3. Monitor your cloud resource utilization. Avoid over-provisioning by continuously monitoring your cloud resource usage patterns to identify utilization trends (your cloud provider probably offers tools for this). This will help you to rightsize your resource commitments based on your actual cloud workloads.

Related: Application Modernization – 3 Common Pitfalls to Avoid

4. Implement autoscaling. Incorporate mechanisms into your workloads to automatically adjust the number of instances or resources you use based on current demand.
5. Consider serverless computing. Serverless computing platforms, such as AWS Lambda, Google Cloud Functions, or Azure Functions, relieve you of the necessity of provisioning and managing virtual servers and allow you to pay only for the execution time you consume.
6. Use cloud-native services. The cloud offers many managed services that often can outperform services implemented in your data center, and do so at a lower cost. For example, using a cloud-native database service such as AWS DynamoDB or Azure Cosmos DB is often far more cost-effective than migrating your on-prem DB solution to run in the cloud.

Reduce Licensing Costs

Licensing costs are an often overlooked but potentially huge element of your overall cloud expenses. AWS makes the point very clearly:

“Without optimizing your licensing in cloud migration, the cost of overprovisioning third-party licensing can exceed the cost of compute.”

And in its lift and shift article IBM adds that your existing data center software licenses may not be valid for the cloud:

“Licensing costs and restrictions may make lift and shift migration prohibitively expensive or even legally impossible.”

Here are some steps you can take to reduce your licensing costs:

1. Inventory your current licenses to determine if any are underutilized, no longer needed, or redundant. Check with vendors and cloud providers to see if it’s possible to transfer your existing licenses to your cloud environment.
2. Proactively negotiate cloud licensing agreements with vendors based on current usage patterns and your assessment of future needs in the cloud.
3. Consider alternatives such as open-source software or subscription-based services that offer a pay-as-you-go model for cost-effective scaling. Explore whether you can use managed cloud-native services that have licensing costs already built in.

Reduce Project Costs

App modernization allows you to:

1. Increase staff efficiency required for maintaining and upgrading your legacy apps and reducing their technical debt. Once apps have been restructured into a microservice architecture they’re far easier to understand and adapt. That means that fewer people are required for managing them than were needed before modernization.
2. Shorten release cycles by adopting a continuous integration, continuous deployment (CI/CD) modernization methodology. By breaking monolithic apps into independent microservices, you allow much of your development and maintenance work to be done in parallel since each microservice is assigned to its own team.
3. Drive increased agility and innovation by leveraging existing cloud-native resources (rather than building from scratch) to minimize the work your developers must perform to create the new apps and features that can propel your company forward in its marketplace.

Setting the Stage for App Modernization

Application modernization can provide substantial cost reductions for your organization’s IT operation. But it’s important to note that significant savings can only be achieved by making extensive use of automation in the modernization process.

The process of analyzing a company’s portfolio of monolithic legacy apps (which may have tens of millions of lines of code and thousands of classes) to untangle hidden dependencies and reveal service boundaries, and then refactoring those apps into microservices, is a highly complex and labor-intensive endeavor. Any attempt to accomplish it using manual methods would be prohibitively expensive in terms of time, personnel, and financial resources.

What’s needed instead is an AI-based automated analysis tool that can produce comprehensive static and dynamic analyses of your legacy apps far more quickly than human engineers could. That kind of accurate, detailed information about the current state of your legacy app estate can then serve as the basis for building an effective modernization plan.

The vFunction application modernization platform can quickly and automatically analyze your apps to assess dependencies, technical debt, service boundaries, and other important modernization parameters. It can substantially automate the process of refactoring a monolithic codebase into microservices, providing your team with significant savings in time, personnel, and money.

To experience first-hand how vFunction can streamline your application modernization efforts and help you to substantially reduce your IT costs, request a demo today.