Introduction to Microservices

Tram Ho


Recently, I was involved in a company project and realized that this project is very big. So its amount of code is certainly needless to say, gigantic. And every time a customer has a change in request, the update is terrible. The project above is a representation of a model that I understand to be called the Monolithic Architecture .

This is a typical model of most projects, which, in my opinion, is not too difficult to develop but to develop and improve is quite difficult.

And that is why the birth of another model seems to make more sense than this old model. That is the Microservices Architecture model . So what is this model and is it different from the previous model? In this article, we will go to analyze it.



For example, if our boss pulled a project on, clear specs, what would we do

Embark on request analysis and code, too. Code from start to finish, this database, this module, this controller, this view, … And after the “en” date, we have a pretty good product. 

Handing over to the customer, the customer is ok, and then delivering the request again.

And this will be the fun part, asking for more features. We will have to analyze and realize that an update is needed in one module, but now that this module updates it affects another module, and this way a bunch of code is updated. And after n requests, we realized that the project compared to the original just need a few times to change the requirements that it is horribly bigger =)) True.


To solve the above problem, the Microservices model has been applied.


Microservice architecture type is an approach to developing an application as a small set of services, each service running in its own process and communicating with lightweight mechanisms, usually an HTTP resource API and it can be written. in different programming languages ​​and using different data storage technologies.


Going back to the above problem, if we apply the Microservices model, we will have the following small service blocks:

As shown above, we can separate the services of that project into sub-components, each of which is a small part that serves a portion of the service for the project, controlled by a different manager. . This ensures that services run independently of each other without being affected by other services as we change.

The linking of these service blocks is then done through the Rest API:

When separating services like this, it is difficult to ensure data consistency between systems, since each service will have its own separate database.

While we benefit from no technology constraints between services, we have a problem of consistency and data synchronization =))


  • Admittedly, the strongest point of this Microservice service model is that it makes the project easy to upgrade and expand.
  • By separating the services into small blocks, when a service dies, the project is still running normally, which is hard to happen with the Monolith model because the services are written together.
  • The freedom to use different technologies in each service helps the project to have more options of its own technologies and databases.
  • Separate functions help focus on developing for each service, easy to change


  • Because of the splitting into sub-services, there will also be sub-databases, so it is difficult to control the consistency and synchronization of data between databases.
  • The method of communication between the services to choose to ensure the ability to communicate
  • Using many services, the monitoring and management of these services will be more complicated

That’s as you can see, there are pros and cons also. In general, which model to apply depends on the development situation of the project members as well as the expansion potential of the project.

Just gossip, hope the article brings some information for you to imagine this development model.

Reference article

Share the news now

Source : Viblo