Monolith or microservices? Both architectures have pros and cons, and each particular case should be investigated. UppLabs had a project with a concrete goal — optimization of application performance by migration from a monolithic system to the new microservices’ infrastructure. We came up with a solution that we’re happy to share with you in detail.
In UppLabs practice, there was a very interesting technical case that we would like to share in detail. We had a project with a concrete goal — optimization of application performance by migration from a monolithic system to the new microservices’ infrastructure. The UppLabs team found a curious approach to fulfill this task.
But first, let’s look closer to some technical terms to understand the case and its challenges.
A monolithic architecture is a technical approach for creating an application that has a single code base with multiple modules, like websites. Modules are divided as either for business features or technical features. It has a single build system that builds the entire application and/or dependency. It also has a single executable or deployable binary.
About ten years ago, many Web-Scale companies (like Netflix, Amazon, Spotify, Uber, etc.) started to realize that the Monolithic architecture approach might bring some restrictions, problems, and special requirements:
1. Application Scaling,
2. Development Scaling,
3. Shorter Time to Market.
The existing Modular Monolithic Architecture or SOA (the Service Oriented Architecture) could not solve their requirements. As a result, a new Software Architecture style was born in 2012: Microservice Software Architecture.
The main characteristics of microservice architecture include:
1. The application contains several processes divided into multiple modules.
2. Regarding Microservice’s functionality and domains, the split of the application is vertical.
3. The boundary of Microservices divides externally, as they connect with the help of network calls.
4. Each Microservice possesses its database.
5. Here we need extra data synchronization because one database can be used only per one Microservice.
It happens quite often that monolithic applications do not scale well to handle super heavy traffic. Monolithic applications, huge ones, almost require supporting software, like application servers and databases. There might be from 5 to 10 million code lines in a big monolithic application, which exercises the supporting software in unique ways. Commercial software can be expensive and harder to deploy than open-source. A 10,000 line microservice is unlikely to exercise the underlying platform that much, which allows you to use just about anything.
Statistics show that:
There are specific difficulties and problems that integrations face while migrating from monolith applications to microservices architecture. Usually, it means that the developers need to rebuild the legacy from scratch. That’s why the whole process leads to the following tech pitfalls:
The main question is — why do the clients consider the use of microservices architecture? The statistic shows, that there are major diﬀerences of up to 79.2% worse performance between monolithic and microservices systems:
Monolith vs Microservices: cons
Let’s consider our case as it shows a great example when the team had to rebuild a monolith architecture to microservices in order to solve the following problems:
On the first stages the visual part of the project looked quite simple:
UppLabs team offered several solutions to the client:
The client approved the second solution and the team started to implement it. During the first brainstorming session, the UppLabs team analyzed the existing application. Besides monolith, the client’s project had problems with code structure, so it has to be rewritten from the very beginning. Our team decided to put the logic into the microservice, creating a Public Getaway API, that can be easy to communicate for both sides — the clients of existing project and the existing businesses.
At the moment the UppLabs team successfully realized the plan, so it has the following structure:
The team already determined the next plan of action for the client in order to scale up the application. We were going to build:
The next stages of realization can take about a year but with constant releases of each stage.
The main challenge for us was to find a solution that can be realized for a short period of time and can solve the client’s business problems. However, microservices architecture can be considered as a complicated solution, it appears to be much easier from the point of potential support and scalability.
Now we’re working on further plan implementation.
Thanks for reading!
Previously published at https://upplabs.com/blog/from-legacy-monolith-app-to-microservices-infrastructure-case-study/
Create your free account to unlock your custom reading experience.