Surely, you have heard two concepts Monolithic and Microservices in the way of organizing, building an application, right? In this tutorial, I will review the basic ideas of these two concepts for someone who does not know about it, or if someone already knew, we can talk more about them.

First, I will talk about the Monolithic concept first. This is a traditional way of building applications, where all the functions and code of the application are packaged in a single package.

To build an application, we usually have three parts: the client-side interface, the server-side logic, and the database systems that our applications will connect to. The server side will receive requests from the user, process logic, manipulate the database if needed and return the results to the user as an HTML interface. According to the Monolithic idea, all of the above will be packaged in a package, with changes to one of the three, requiring us to have to re-deploy the entire application.

Monolithic can be good for small applications where the functionality of the application is low, requiring little time to get used to when new people work on the project. But if the functionality of the application is getting bigger and bigger then we have to look at it again. Maintaining code is going to be harder, changing the code or fixing a bug requires a developer to understand the application so that it does not affect the logic of other features of the application.

I am also experiencing a similar situation when the project I am doing has too much business logic knowledge and too complex code. Requiring new member to have a lot of training time, code design is so complex that new graduates who come to their project, usually feel it difficulty. And changing the code at the request of customers requires you take more time to review the code, to see if this change has any impact on the business of the application or not?

To address these inadequacies, the Microservices model was introduced. With this model, our application, instead of all functions, is packaged in a single package, now divided into different parts, each of which is called a service. These services will exchange information with each other through APIs with HTTP connections.

By combining these services together, we will still have a complete application according to customer needs but in the style of Microservices.

The separation of services according to Microservices will depend on the requirements of the application and will be proposed by the application designer. But there are rules that force each service to respond that the service must be deployable independently, without affecting other applications and can be easily extended.

Another need can influence how the services are divided, which is the need to use many programming languages in a Microservices system. This service can use Java with Spring Boot, another service can use NodeJS, …

Breaking up like that, let’s imagine, we will have many benefits, can be said as:

• Easy maintenance of code
• Easy to understand the functions of the application
• Easy access for new people.
• Release of new features will be quick thanks to the use of CI/CD pipeline deployment mechanisms.

However, there are some things that can happen to many people using Microservices:

• Since we split the application into multiple services, it can be more difficult to manage the services.
• Breaking down services, sometimes also a headache for designers.
• With Microservices using a variety of technologies, newcomers are required to get used to those technologies in order to work.