Monolith vs Micro-Services Everything you Need To Know

One of the major choices you need to make before you start building an application is the structural architecture to use. Microservices and monolithic architectural designs are two of the most popular models used to create web applications. However, most of the web applications operating on a large scale now use the microservices architecture.

There are several other use cases where it makes more sense to choose microservice over monolithic architecture. In today’s article, we shall discuss all the major things you need to know about microservices, how they work, their pros and cons, best use cases, and a lot more. Let’s dive right in!

What are microservices?

Microservices is an architectural design where a big application is developed by building small autonomous services that work together to execute the various functionalities of the app. For instance, an eCommerce web application might have different microservices for the various functionalities including, registration, order management, Wishlist, search, etc.

Each of these microservices works independently, so a fault in one does not affect the operation of the others. With the monolithic architecture, an error in one section of the app will affect the functionality of the entire application. Some of the popular platforms that use the microservices approach include; Netflix, Amazon, Uber, eBay, and many more.

How do microservices work?

The way microservices work depends on the size and scale of the application. However, there are four main modules that all apps built using this architecture have. These include the API gateway, microservices, database, and Inter-microservices communication. Let me explain each of these in detail.

API Gateway: An API gateway is the entry point for the final users of the applications. The users of the app send the request to an API which then forwards it to the given microservice that was built to handle that task. For instance, when you click the sign-up button on a given web app, that request is sent to the registration microservice.
Database: The app developer can choose to have one database for all microservices. However, if you want all the services to be fully autonomous, it is best to have a database for each microservice.
Microservices: These are the small services that perform independent tasks such as payments, registration, search, order management, etc. The number of microservices may at times depend on how big the application is or how the developer decides to split up services. For instance, Netflix has over 1000 microservices.
Inter-microservices communication: Microservices communicate using different kinds of protocols such as REST and messaging. These enable the different microservice of an application to communicate whenever the need arises.

Advantages of using the microservices architecture

Easy fault isolation: With the microservices architecture it is much easier to isolate one service while the rest of the app is working. A similar fault could potentially lead to downtime of a monolithic application if the fault is severe enough.
Faster and more effective development of the app: Different teams can work on the various microservices without having to wait for another team to finish a specific section of the app.
Apps are more scalable: It is much easier to add new features and manage huge traffic. With microservices, each small service is built independently, so adding new features can be done much faster.
It is easier to use different technologies: With microservices, you can use different programming languages for each service without affecting the overall operation of the app. The procedure for using different languages for different sections of monolithic apps is more complicated.
Easier to understand: If there is anything to fix or changes to be made in a certain microservice, it is much easier to do such a task. This is because the size of code for the various microservices is small, so making changes can be done much faster even if the team working on this service is small.
Easier continuity: It is much easier for a new team member to understand the functionality and code of a microservices than the entire application. This makes continuity much easier.
Apps feel much faster on the user side: Apps using this architecture tend to load the various sections of the app much faster. This improves the overall user experience of the application.

Limitations of the microservices architecture

More complex deployment: Since a single application has multiple microservices, it is much harder to deploy on the web than monolithic applications. The communications infrastructure between the different services is also very sophisticated, hence making the app more complicated to deploy.
Requires more resources: Due to the complex networking involved to enable communication between the different services, apps built with the microservice architecture tend to take up a lot of computing resources than monolithic apps. This is an extra expense that the app developer needs to deal with.
Global testing and debugging are harder: It might be easier to test and detect errors for the individual microservices. However, testing the functionality of the entire app is much harder with this architecture.
Not ideal for small apps: Microservice architecture only makes sense for big apps that expect to get thousands or millions of users every day. For smaller apps, you are better off going for the monolithic architecture.

When to choose micro-service over monolith infrastructure

Yes, apps built with microservice architecture have several advantages over those built using monolithic architecture. However, this architecture is ideal for certain situations that you may need to know about before making the choice. Below are some of these scenarios.

When the main goal is to build a large-scale application that has the potential of attracting millions of users. However, if you are deploying an app that is to be used internally in your organization, it is best to use the monolithic architecture.
If the different functionalities of your app’s backend have to be coded in different languages. As we have earlier discussed, one of the benefits of using the microservices approach is it makes it easier to write the backend of every service using a different programming language.
If scalability is key to your application. Microservice architecture is ideal for apps that need constant revision and scaling up their user capacity.
When the app you intend to build has multiple functionalities and user journeys, it is best to develop it using the microservices architecture. For instance, an app that has several standalone business modules should be built using the microservice architecture.

How to handle microservices requests to other micro-services

One of the crucial factors that affect the performance of any web app built using the microservice architecture is how they communicate. Different microservices have to effectively communicate to execute a certain business task. There are three messaging patterns that microservices use to communicate with each. These include; Synchronous, asynchronous, and hybrid. Let’s explain each in detail.

Synchronous communication
This involves data moving to and from the endpoint in blocking iteration. That means the caller has to wait for a response from the receiver before proceeding to the next step. So, if microservice A sends a request to Microservice B, it has to wait for a response before sending any other requests

Asynchronous
With this communication protocol, a microservice sends messaging without having to wait for a response from the receiver.

Hybrid
A hybrid microservice supports both communication protocols. Most microservice apps use both protocols. So, the choice of which one to use depends on the type of communications that take place between the different microservices of a given application.

How database transactions can be handled on microservices

With monolithic apps, all data is in a single database, hence making it easier to achieve consistency in the various database transaction. However, with microservice apps, the different microservices have independent databases, so database transactions are distributed. This makes it more challenging to achieve consistency across all the databases in the network.

Monolithic apps databases handle ACID transactions to execute all-or-nothing transactions while ensuring consistency. ACID stands for;

Atomicity: All requests are executed successfully or everything fails .
Consistency: All data in the database is kept in a valid state as stated by the rules of the database.
Isolation: separated transactions do not interfere with each other .
Durability: After a transaction is complete, all changes are stored permanently.

As you may guess, the ACID transactions methodology does not work with microservice apps since the different microservices databases are distributed on a network. There are two main challenges faced in handling microservice database transactions;

How to keep the transactions atomic and
How to handle concurrent transactions

The solutions used to fix these two challenges are as follows;

Two-phase commit: This includes the prepare phase and the commit phase. In the prepare phase, all the relevant microservices for a given transaction inform the coordinator that they are ready for the transaction. During the commit phase, the coordinator either issues a commit or rollback command.
Eventual Consistency and Compensation: With this approach, all microservices publish an event whenever there is a change in its data. The rest of the services subscribe to this event and update their databases to ensure consistency.