From legacy monolith app to microservices infrastructure. Case study

In UppLabs practice, we came across 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 with a single code base with multiple modules, like websites. Usually, we can divide modules for business or technical features. It has a single build system that builds the entire application and dependency. The module consists of a single executable or deployable binary.

Some giant companies like Etsy remain monolithic despite the popularity of microservices today. Monolithic software architecture can be useful if your team is in the early stages, you are building an untested product, and have no experience with microservices. Monolith is ideal for startups looking to get a product up and running as quickly as possible.

Microservice Architecture

The main characteristics of microservice architecture include: 

• The modules can be easily replaced at any time: they are simple, independent in deployment, and updating processes.
• The modules are organized around functions: the microservice performs only one basic function.
• The modules can be implemented using various programming languages and frameworks, executed in various environments, with the use of various operating systems on different hardware platforms.
• The architecture is symmetric, not hierarchical.

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. A big monolithic application might have 5 or 10 million code lines, 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 condition, only code
• technical issues: technologies, approaches, practices

Monolith vs Microservices: a general comparison

The main question is – why do people want to change the microservices architecture? The statistic shows that there are significant differences of up to 79.2% worse performance between monolithic and microservices systems:

Monolith

• A typical monolithic application consists of a database, a client user interface, and a server application.
• All pieces of software are unified and all of its functions can be managed in one place.
• The components of monolithic software are interconnected and interdependent.
• Monolithic applications enable fast communication between software components through shared code and memory.

Microservices

• Microservices mainly get their name from the fact that there are fewer services than in a monolithic environment.
• In a microservice architecture, smaller services interact to perform tasks related to their business capabilities.
• Here, you have multiple deployment units. Each service is deployed independently.
• Smaller sizes help when it comes to compiling time, run time, and time required to run tests. 

Monolith vs microservices: Cons

Monolith

• This development process is slower: each feature can be harder to develop. Because the components work together, they also need to be changed together.
• Scaling can be problematic when only one part of the system requires additional resources because, in a monolithic architecture, it’s challenging to scale separate parts of the system.
• There is practically no insulation in the monolith. A problem or bug in a module can slow down or destroy the entire application.
• Disabling or updating the initial choice of basis can be difficult because it must be done at once and for all parts of your system.
• As the codebase grows, the quality deteriorates and the IDE becomes overloaded.

Microservices

• A distributed system has its complexity: you have to deal with partial failures, more difficult interactions when testing (E2E tests), and higher complexity when implementing communication between services.
• Many microservices are more challenging to maintain than a few instances of a signal monolith.
• Microservices may also require more hardware than traditional monoliths.
• Changes affecting multiple services need to be coordinated across various teams, which can be difficult if teams have not yet had worked together.

Monolith vs microservices: Pros

Monolith

• You can quickly start implementing your business logic in a monolithic architecture instead of wasting time thinking about interprocess communication.
• It’s easier to implement end-to-end (E2E) tests. 
• When it comes to operations, it’s easier to deploy and to scale a monolith.
• Monolith is the fastest and cheapest way to implement a small system.
• Monolithic architecture is convenient for small teams.
• There are many tools you can integrate to make development easier.

Microservices

• Microservices are easier to keep modular. Technically, this is ensured by rigid boundaries between individual services.
• Microservices are smaller, and therefore, it’s easier to understand and test them.
• There is no need to coordinate deployment between teams. It is better to develop services with an increase in the number of teams.
• Smaller parts of microservices affect developer productivity as they allow them to spend less time waiting at each stage of development.
• Microservices are not connected to the technology used in other services. Old services can be quickly rewritten to use new technologies.
• Microservice architecture is easy to fix – you always know exactly what is broken and where exactly is the problem.

UppLabs’ 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:

1. 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.
2. 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. 

How UppLabs can help

Our IT consulting agency works end-to-end together with the clients discussing all possible scenarios and questions, starting from strategy to digital, we bring transformational outcomes. This is UppLabs’ task to show you the opportunities, needs, and threats. 

Our assurance as an IT advisory service includes:

1. Designing and applying appropriate project management standards
2. Planning and monitoring the project (timelines and budget)
3. Managing project risks
4. Ensuring customer satisfaction
5. Organizing and motivating a project team
6. Creating detailed, comprehensive and well-structured technical documentation
7. Estimating, prioritizing, planning and coordinating testing activities
8. Developing and applying development and testing processes for new and existing products to meet client needs
9. Discovery session
10. CI/CD (Continuous Integration and Continuous Delivery)

So, you can always book a call with Upplabs and delegate the task with a value proposition to us!