Monolith to Microservices: Successful Transition of a Fintech Application
Learn when it's wise to Transit from Monolithic to Microservices architecture
Insights on How we successfully upgraded a fintech app from monolith to microservices
Dive in to learn more!
Table of Contents
There is a lot of talk about the pros and cons of monoliths, microservices, and when to use which. But what happens if your monolith has outgrown its original purpose? How do you know when it’s time to transition away from a monolith architecture?
This article is for those whose monolith has ceased to cope with solving problems and only aggravates all processes. It will also come in handy for those who are just getting acquainted with microservices. We will share our experience of moving a Fintech App from a monolith to a microservice architecture.
Monolith To Microservices – Consider All Risks When Choosing An Approach
Global companies have been using microservices for a long time. For example, the monolithic apps of Amazon, Coca-Cola, and Netflix have evolved into larger infrastructures at some point. Brands benefited from this decision and attracted even more audiences. But the trend does not mean that the monolith is yesterday. We are not used to blindly chasing newfangled trends. We always analyze when this or that option is effective and how it is safer to switch to it.
One of the Fintech products we built was based on Monolith architecture. This approach is reminiscent of a Rubik’s cube: if you take one piece out of it, assemble a new shape, or add other components, the cube will no longer work fully. Each element forms a single functionality. If some part is missing, broken or not in place, the coloured field will not fold.
Why Did We Choose A Monolith to Develop the App?
Firstly, the customer was a startup and in a startup environment, it is possible to launch a project faster with the monolith. When conditionally in a month, it is necessary to present the MVP to the client, but there are no specific requirements or specifications for the product—only the monolith saves. Its flexibility comes in the variety of tools that can be integrated to simplify development. Besides, you can deploy changes or updates all at once, rather than individually. Secondly, at the start, the monolith is easy and fast to scale. For our team, the benefits were clear.
More specialists, including beginners, can join the development on the monolith. It is simple and straightforward to use. In such an application, all the components are interconnected and interdependent. Any beginner will find it much easier to understand the code and logic implemented in the monolith than in microservices.
Why Did We Shift From Monolith To Microservices Later?
With the successful implementation and a great user experience, the startup has grown rapidly. The number of users and clients grew, various functionalities were regularly added. After some time, the shortcomings of the monolith appeared, which was critical for us:
- Due to the rapid growth of the system, it became more difficult to maintain and develop it without additional resources. First, this concerned the cost of introducing new changes. The further we went and introduced new features, the more they became expensive;
- Getting stuck on old technologies in the future. I think many colleagues have come across legacy monoliths – outside the window in 2020, and on the monitor in the code 2003. It is extremely difficult to rewrite all this. Usually, there is not enough time or resources.
Fortunately, we foresaw the risks in advance, so the transition to the new architecture was not shocking. Everything went smoothly and calmly. The microservice approach solved several problems.
The reuse of microservices made it easier to adapt to the new requirements of a startup and scale it up. Now we know that to prepare MVP, it is better to take a monolith, and then as the project grows it is up to microservices.
Introducing New Functionality At No Extra Cost And Simplifying The Integration Of Subsequent Applications:
We decided to move away from strong monolithic cohesion. Most of the functions were divided into small, independent groups and are implemented as microservices. Subsequent changes or new features were introduced within a group or separately as another microservice. At the same time, nothing superfluous is affected. What is especially pleasing: there was freedom in the choice of technologies and languages. Each of them has its advantages.
We used different programming languages for microservices and different types of protocols for communication between them.
But shortcomings immediately surfaced. First, the threshold for entering the project has increased. Second, it has become more difficult to maintain, configure, and test the settings. This is not a minus. The main thing is that microservices have closed the most important questions.
Over time, the customer realized that he wanted to sell the product not only as a whole but also in separate parts, thereby making life easier for users. At that time, we already had various functionalities from which we planned to single out small, independent components. And from them, to build identical designs or create new business solutions.
Each microservice has its logic and functions, but this puzzle can be integrated into any other system and independently developed. If one of the components stops working, this does not mean that the entire system will necessarily collapse. Something that is closely related to this microservice will fall off. But in one form or another, the system will continue to work.
The good thing about microservices is that they can be deployed and tested independently of each other. This makes life easier for the team at all stages.
What Microservices Gave To Our Project?
- PHP and Golang interaction: They compliment each other perfectly and sometimes overlap weaknesses. Compared to PHP, Golang can significantly improve performance. Due to parallelism, speed up the processing and execution of certain processes. At the same time, PHP has everything to quickly implement a convenient CRUD;
- The transition from five large clients to more than 20 – all thanks to the differentiation of the monolith into separate solutions;
- Optimization of server load: Compared to PHP, Golang consumes a lot less memory. With the introduction of Golang into the project and the rewriting of individual parts in Go, it became easier for servers. We no longer face this problem;
- Diversity of the team: Moving to microservices is not only about changing the architecture of the code but also about the team itself. We have divided by areas of responsibility. Once, there were eight of us working on the monolithic app, now there are about 40 people. Backend developers and business analysts have been added, tailored to specific requirements.
So we have successfully transformed from a monolith application to a microservices based product. But Not without difficulties for the new team members. They need more time to understand how microservices interact with each other and if they do it at all. How deep should a beginner developer understand this? The more diverse the knowledge base, the more valuable the specialist is in the market and can react more quickly to changes in the project.
So it’s always a wise decision to hire experienced developers when migrating from a monolith application to a microservices-based application or you could simply outsource to a software development company with experience in transforming from a monolith app to a microservices.
When there is something to compare with, it is much easier to choose the most suitable one at the moment among several options. Therefore, I advise everyone to at least familiarize themselves with this architectural approach. A new product can start with simpler things – a monolith—but remember that someday you will have to delve deeper into microservices, especially if you have a SaaS product.
Monolith to Microservices: Which Is Better
The monolith is like a hefty cauldron in which a lot of things are cooked at once. With the advent of new “ingredients”, we tried to structure everything. But stirring this “soup” touched on other “ingredients”, even when it was not required. Microservices have helped create a modern technological kitchen and divide the functional areas. We already not only “cooked”, but also “baked”, “boiled”, somewhere “fried”, and somewhere only “warmed up”. Having learned the intricacies of this haute cuisine, the result is quality products.
There is no one-size-fits-all answer and no final solution. In certain situations, it is more logical to start from a monolith. In the future, the system may reach such a scale that the transition to microservices is inevitable. From personal experience, I noted a couple of scenarios in which you should think about switching to microservices:
- When in a monolithic project, the cost of a new functionality does not cover the expected benefit;
- When the project grows to such a lump that new people in the team are lost. In microservices, you can take a separate component, determine what is happening in it, and work only with it. In large projects, the separation of duties will sooner or later lead to architectural delineations. Microservices make it easier to relive this moment.
Sometimes we run into persistent customers who give up on a sound idea from the developers. The customer just decided to use this technology or architecture. Why? Because. “I heard it on the Internet” or “everyone else does it”. The client rarely thinks about the pitfalls that programmers may stumble upon.
We understand that if you see that there is a certainty that the customer’s idea will cause new problems or stop the development of the project altogether, your task is not to be afraid to tell the client that he is wrong. You need to explain why it is better to use a particular technology. As practice shows, when you can argue the advantages of your idea and the disadvantages of the solution proposed by the customer, he will calmly take your side. The project is his brainchild, his money, and above all, the client is interested in the efficiency and profitability of the product.
We developed many specifications that lived in isolation and did not fully interact with each other. And as soon as we split them into independent microservices, we got high rates in performance and a happy customer who multiplied profits.
My main message is – do not compare, but adapt to the specifics of the project and business goals. Choose your application architecture carefully. The right option will make life easier for you, your team, and your users. And in general, it will make the project more successful.
Looking to transition from a monolith to a microservices based application? We successfully did it for many customers and know what works and whatnot.
Contact Us Today