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.
Monolithic architecture
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.
Microservice 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.
Why do we need to migrate?
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:
- Today, 68% of companies are already using microservices in production and development
- 36% of large companies, 50% of medium companies, 44% of small companies are using microservices in production and development
- 26% of companies are researching microservices but have not yet begun to implement them
- Teams moving to microservices reported a 13x increase in the frequency of software releases
Difficulties
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:
- time
- money
- no requirements or no actual requirement, only code
- technical issues: technologies, approaches, practices
Monolith vs microservices: a general comparison
The main question is — why do the clients consider the use of microservices architecture? The statistic shows, that there are major differences of up to 79.2% worse performance between monolithic and microservices systems:
Monolith
- The application runs as one single process.
- The complete Software System is deployed as a whole.
- The Modular boundary is internal and can be crossed easily, which can lead to the unstructured and difficult-to-maintain source code.
- No strict data ownership among modules.
- It is one size for all, that leads to one solution for all sizes of application.
Microservices
- Deployment is a complex process in microservices. Each microservice needs to be implemented separately, which leads to the extension of the implementation process.
- If something goes wrong, only one microservice will be damaged, and it will be easier to fix it.
- Maintenance in microservices is faster than in monolith. Smaller services are also easy to test, saving time.
- Microservices are stable and reliable. Breaking one part only affects one element, while the others remain intact.
Monolith vs Microservices: cons
Monolith
- Because of shared Codebase and shared data sources, it is difficult to parallelize works among multiple teams. It makes development scaling a complicated process.
- A sizeable monolithic code-base leads to immense cognitive complexity for the developer. As a result, the development velocity is low.
- Granular scaling is not possible.
- Modernization is becoming hard due to Monolithic applications’ characteristics.
Microservices
- Splitting the whole system vertically needs extreme inventiveness. Also, breaking one database into multiple databases and then sharing data among them is a scary task. So, designing the whole system is more complicated.
- Code complexity often causes operational complexity.
- Because of multiple databases (which are usually distributed), data sharing and transaction management are highly challenging.
- The numerous moving parts lead to the complexity of application security.
- The external network calls cause a higher overall latency of the whole application.
Monolith vs Microservices: pros
Monolith
- Monolith parts are moving. As a result, it is easier to design, deploy, and test a Monolithic application.
- Less moving parts leads to a smaller surface area that can be attacked. So, it is easier to protect a Monolithic application.
- The operational complexity is low.
- Monolithic application’s database has a single OLTP (Online Transactional Processing), so it makes it easier to process transactions and data sharing.
Microservices
- Different teams can work simultaneously on other Microservices independently with little external dependency.
- The size of the Microservices is relatively small. It means low cognitive complexity for the developer so that they can be more effective.
- Each Microservice is a separate process that doesn’t require the whole teamwork. It brings a faster release cycle for microservice architecture.
- Granular scaling of the application can be another option here.
- As each Microservice has its database, it’s possible to apply for granular data ownership.
- The possibility of the external contract makes it possible for Microservice to replace its parts quickly. That makes the Microservice application accessible for modernization.
Case study
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:
- the server hung up when the amount of the active users were more than 3000;
- monolith architecture that did not allow scaling up;
- not optimized code (backend);
- a lot of triggers in the database (almost every table had 3 triggers) became performance “killers”;
- business logic in triggers, stored procedures, backend code — C#;
- hard to support legacy code in order to add new features that business expects;
On the first stages the visual part of the project looked quite simple:
Two solutions
UppLabs team offered several solutions to the client:
- Rewrite the application from scratch to microservice architecture and following the best code practices. It required more than 1 year of the development of a team of 5+ members.
- Implement 1 microservice that covers a small part of the functionality but the most used one and which brings the biggest performance issues. This required around 2 months of the development of 2 team members.
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:
- One more microservice that will be responsible for the difficult part of business logic and big data processing
- Another microservice that will be responsible for user management
- A PDF microservice that will be responsible for files generation
- An email microservice that will be dealing with mailing lists and templates
The next stages of realization can take about a year but with constant releases of each stage.
THE RESULT
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/