Unleashing Potential: A Deep Dive into a Strangler Fig Pattern Example

Miranda Rudy-Nguyen

August 22, 2023

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.

Miranda Rudy-Nguyen

Get started with vFunction

See how vFunction can accelerate engineering velocity and increase application resiliency and scalability at your organization.