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.
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.
In the 2010s, many Web-Scale companies (Netflix, Amazon, Spotify, Uber) started to realize that the Monolithic architecture approach brings some restrictions, problems, and special requirements:
- Application Scaling,
- Development Scaling,
- Shorter Time to Market.
The existing Modular Monolithic Architecture or the Service Oriented Architecture (SOA) 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:
- The whole application split into separate processes where each process can contain multiple modules.
- Contrary to Modular Monoliths, a Microservice application is split vertically
(according to functionality or domains).
- The Microservice boundary is external – microservices communicate with each other via network calls.
- Instead of one single database, each Microservice has its database.
- Extra data synchronization is needed due to “database per Microservice”.
Why do we need to migrate?
It happens quite often that monolithic applications do not scale well to handle super extremely heavy traffic. Monolithic applications, especially large ones, almost require the use of supporting software, like application servers and databases. A big monolithic application might have 5 or 10 million lines of code, 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 ever 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
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:
- 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 diﬀerences of up to 79.2% worse performance between monolithic and microservices systems:
- The complete Software System is deployed as a whole (all or Nothing).
- The Modular boundary is internal and can be crossed easily which can lead to Spaghetti Code.
- The application runs as one single process.
- It is one size for all, that leads to one solution for all sizes of application.
- No strict data ownership among modules.
- 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
- Because of shared Codebase (which is often Spaghetti code) and shared data source, it is difficult to parallelize works among multiple teams. It makes development scaling a complicated process.
- Large Monolithic code-base (often spaghetti code) leads to immense cognitive complexity for the developer. As a result, the development velocity is poor.
- Granular scaling (scaling part of the application) is not possible.
- Polyglot programming or polyglot database becomes a challenging process.
- Modernization is complicated due to Monolithic applications “All or Nothing” nature.
- Splitting the whole system vertically needs extreme craftsmanship. 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 (many processes, databases, network calls, containers, VMs) leads to the complexity of application security.
- The external network calls cause a higher overall latency of the whole application.
Monolith vs microservices: Pros
- Monolith has some moving parts (e.g., one process, one App Server, one Database). As a result, it is easier to design, deploy, and test (system test, e2e test) a Monolithic application.
- The smaller amount of moving parts means there will be a smaller surface area to attack. As a result, it is easier to secure a Monolithic application.
- Low operational complexity.
- Monolithic application has one single OLTP (Online Transactional Processing) database, so it makes it easier to manage transactions and data sharing.
- Better development scaling as teams can work parallelly on different Microservices in an Autonomous way with little external dependency.
- The size of the Microservices is relatively small. It means low cognitive complexity for the developer, so they can be more productive.
- Each Microservice is a separate process and can be deployed independently. It brings a faster release cycle for microservice architecture.
- Granular scaling of application is possible in microservices.
- Granular data ownership is another option as each Microservice has its database
- While an external contract is maintained, a Microservice can quickly be replaced like Lego Blocks. That makes the Microservice application easier in modernization.
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:
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 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:
- Designing and applying appropriate project management standards
- Planning and monitoring the project (timelines and budget)
- Managing project risks
- Ensuring customer satisfaction
- Organizing and motivating a project team
- Creating detailed, comprehensive and well-structured technical documentation
- Estimating, prioritizing, planning and coordinating testing activities
- Developing and applying development and testing processes for new and existing products to meet client needs
- Discovery session
- CI/CD (Continuous Integration and Continuous Delivery)