Fintech is no longer just another buzzword; it is an essential part of our everyday life. Even if you don’t trade bitcoins and don’t know how stocks work, there is a chance you still have used one or two fintech apps, e.g. online payments or mobile banking solutions.
In fact, the number of fintech startups worldwide has grown from 12,131 in 2018 to 20,925 in 2020. This stunning 72% growth in just two years demonstrates that fintech app development will only continue to expand, swallowing the old ways of data handling and instilling new standards of financial operations.
After working for more than 4 years in the Finance domain, I realized that most of the FinTech applications that run on production are very old, which uses old technology and stale architecture. They were built quite a few years ago (maybe in the late ’80s, ’90s or even earlier) and are still running on production. Over time with increasing business needs, many new features were added to existing products, and now they become Monolith- a big ball of Mud.
In this article, I am going to discuss how to migrate an extensive monolith application to microservices. But before that, we need to understand when the Monolith is problematic and what are the reasons behind that:
– They were built with technologies that are now obsolete. For example, using a Java applet in the ’90s was a good choice, but nowadays, it’s certainly not.
– Since technology is obsolete, it’s tough to maintain and even very hard to find a developer willing to work on the old/outdated technology.
– Over time, many features are added in the application in the same codebase, and it becomes huge in size. This makes the codebase very hard to maintain, develop, and deploy.
– A slight change in the big codebase has to go with all the complex processes of testing, which itself is a time-consuming process (especially for old monoliths).
Now that we realize how complex it is to manage and maintain Monolith applications, we should think of some strategy from Monolith to microservice architecture. So here comes Strangler Fig Pattern to rescue.
Before discussing the solution of giant monoliths using the Strangler Fig Pattern, first, we need to understand why we need to refactor a monolith app.
If you’re in monolithic hell, it is very likely that you already have at least one business problem. Here are some examples of business problems caused by monolithic hell:
Slow delivery: The application is difficult to understand, maintain, and test, so developer productivity is low. As a result, the organization is unable to compete effectively and risks being overtaken by competitors.
Buggy software releases: The lack of testability means that software releases are often buggy. This makes customers unhappy, which results in losing customers and reduced revenue.
Poor scalability: Scaling a monolithic application is problematic because it combines modules with different resource requirements into one executable component. As a result, the application can’t support the current or predicted needs of the business. The lack of scalability means it’s either impossible or prohibitively expensive to scale the application beyond a certain point.
Now we understand the problem, so it’s time to find a way to come out of this problem.
Strangler Fig Pattern:
It is the process of transforming a monolithic application (that is very hard to manage and maintain) into microservices in the form of application modernization. Application modernization is converting a legacy application to one having a modern architecture and technology stack. Developers have been modernizing applications for decades. As a result, wisdom is accumulated through the experience we can use when refactoring an application into a microservice architecture.
The most important lesson learned over the years is to not do a significant bang rewrite. As Martin Fowler reportedly said, “the only thing a Big Bang rewrite guarantees is a Big Bang!”.
Instead of doing a significant bang rewrite, you can see incrementally refactor your monolithic application in the figure below. You gradually build a new application, which is called a Strangler application. It consists of microservices that run in conjunction with your monolithic application. Over time, the amount of functionality implemented by the monolithic application shrinks until it either disappears entirely or becomes just another microservice.
Advantages of Strangler Fig pattern:
Demonstrate value early and often:
An essential benefit of incrementally refactoring to a microservice architecture is getting an immediate return on your investment. That’s very different from a significant bang rewrite, which doesn’t deliver any benefit until it’s complete. When incrementally refactoring the Monolith, you can develop each service using a new technology stack and a modern, high-velocity, DevOps-style development and delivery process. As a result, your team’s delivery velocity steadily increases over time.
Another benefit is, you can migrate the high-value areas of your application to microservices first. That will give businesses one step ahead of their competitors. This incremental nature of refactoring to microservices means that the development team can demonstrate value early and often.
Minimize changes to the Monolith:
When we use the Strangler pattern to migrate a monolith to a microservice architecture. You should avoid making widespread changes in monolith applications. The problem with making general changes to the Monolith is that it’s time-consuming, costly, and risky.
After all, that’s probably why you want to migrate to microservices in the first place. In this approach, we can carefully apply the logic to set the sequence of extraction of service to reduce the impact on the Monolith and extract the frequently changed component early. That will also minimize the frequently changing occurrence of the Monolith.
Technical deployment infrastructure: you don’t need all of it yet:
By using this architecture, we can reduce the infrastructure cost from the beginning. As we follow this pattern, we need a small infrastructure to start migrating with one microservice. This will also help us identify a suitable technology stack that will fulfil our business needs ideally.
As we know that technical infrastructure involves a significant investment. So before going to take any big decision, we can validate each aspect of our target infrastructure early by designing one microservice. That will help us to make the right decision at the right time.
Run both Applications simultaneously:
One of the most significant benefits of this pattern is the flexibility to run both Monolith and all converted microservices simultaneously to fulfil the needs of the business without having any impact on our customers.
We have understood the most significant business problems of an extensive monolith application and how the Strangler Fig pattern helps migrate this giant Monolith into a microservice-based approach.
Now, we have a question, what is the right strategy to implement this pattern to refactor a giant monolith.
Strategies to implement Strangler Fig pattern:
There are three main strategies for strangling the Monolith and incrementally replacing it with microservices:
- Prepare Automation E2E test.
- Implement new features as services.
- Separate the presentation tier and backend.
- Break up the monolith by extracting functionality into services.
Let’s take a look at each strategy in detail:
Prepare Automation E2E test:
In SDLC, whenever we modify or refactor any software, we need to perform regression verification over the changes done to validate that no feature is breaking. The same philosophy is also applied here. Before using this Strangler Fig pattern to refactor this large monolith app into smaller microservices, we must have an E2E automation test in place, covering all possible scenarios and business use cases of our monolith app. This will help from time to time verify our changes as a whole at any point in time.
Implement new features as services:
If you have an extensive, complex monolithic application, don’t implement new features by adding code to the Monolith. That will make your Monolith even larger and more unmanageable. Instead, you should implement new features as services.
This is a great way to begin migrating your monolithic application to a microservice architecture. It reduces the growth rate of the Monolith. It accelerates the development of the new features because you’re doing the action in a brand new codebase. It also quickly demonstrates the value of adopting the microservice architecture.
After implementing a new service, we need to integrate it with a running monolith app to fulfil the business needs. To do this, this architecture includes two other elements that will help us to integrate the service into the monolith application.
- API gateway: Routes requests for new functionality to the new service and routes legacy requests to the monolith.
- Integration glue code (Adapters): Integrates the service with the monolith. It enables the service to access data owned by the monolith and to invoke functionality implemented by the monolith. It consists of adapters in the monolith and the service that use one or more interprocess communication mechanisms like (REST, RMI, GRPC, etc) to connect with the monolith app.
Separate the presentation tier and backend:
As we know that, a typical enterprise application consists of the following layers:
- Presentation logic: It consists of modules that handle HTTP requests and generate HTML pages that implement a web UI.
- Business logic: It consists of modules that implement the business rules, which can be complex in an enterprise application.
- Data access logic: It consists of modules that access infrastructure services such as databases and message brokers.
As you can see that there is a clean separation between the presentation logic and the business and data access logic. So we can split this giant Monolith into two parts- one application contains a presentation layer, and the other includes the business and data access logic.
Splitting the Monolith in this way has two main benefits. First, it enables you to develop, deploy, and scale the two applications independently of one another. The second benefit of this approach is that it exposes remote APIs called by the microservices you develop later.
Break up the Monolith by extracting functionality into services:
Suppose you want to significantly improve your application’s architecture and increase your development velocity. In that case, you need to break apart the Monolith by incrementally migrating business capabilities from the Monolith to services.
When you use this strategy, the number of business capabilities implemented by the services grows over time, and the Monolith gradually shrinks.
The functionality you want to extract into a service is a vertical slice through the Monolith. The slice consists of the following:
- Inbound adapters that implement API endpoints. Which is responsible for taking inputs from other services or end-users.
- Domain logic is independent or isolated business logic.
- Outbound adapters such as database and other service access logic.
In the below figure, we can clearly see how we can split or, let’s say, extract new services from a large monolith codebase.
But before going to split or extract service from a monolith, we have to plan to figure out which components or features of a giant monolith that we need to do the refactoring first. Here is the approach that will help us to identify the eligible members for refactoring.
First, we need to rank the modules of an application by the benefit you anticipate getting from extracting them. There are a few reasons why extracting a service is beneficial:
- Accelerates development: If your application’s roadmap suggests that a particular part of your application will undergo a lot of development over the next year, then converting it to a service accelerates development.
- Solves a performance, scaling, or reliability problem: If a particular part of your application has a performance or scalability problem or is unreliable, then it’s valuable to convert it to a service.
- Enables the extraction of some other services: Sometimes extracting one service simplifies the extraction of another service, due to dependencies between modules.
You can use these criteria to add refactoring tasks to your application’s backlog, ranked by expected benefit. The benefit of this approach is that it’s more strategic and much more closely aligned with the needs of the business. During sprint planning, you decide whether it’s more valuable to implement features or extract services.
A group of Knoldus engineers at present working with Singapore’s one of the biggest FinTech firms. The firm has a trading platform with many traders and brokers and does billions of transactions every year. They want to scale the platform and also want to add new features for their customers. But the problem is that the platform is very old, built with old technologies, architecture, and design patterns. Basically, the platform is a monolith, and making a single change on that Monolith adds a lot of risks, time and increases the development cycle.
So the Knoldus Engineers decided to use the Strangler Fig Pattern to break the Monolith into multiple microservices (and, of course, without impacting the running production).
At first decided to introduce the automation tests so that every change in the source code can be traced, especially when changes are causing ripple effects. This builds confidence among the team and also improves overall productivity. After that, we have used the Strangler fig strategy to implement new business features as in a separate service.
Also, we are continuously identifying and extracting the most eligible features from monolith code and implementing a new service or utility. So that we make sure that both systems run simultaneously and intact the business features.
We invite you to attend the Financial Service Week from October 25, 2021, to October 30, 2021. Optimizing the month of October with this, a virtual event that will share a 360-degree exposure on everything we need to know while working with Financial Technologies.
Be our Guest: https://lnkd.in/gFh2E84x
Know more details: https://lnkd.in/gcYBrcDq