Typically, there are a minimum number of services that handle things common to others (such as database access), but each microservice is small and corresponds to a different area of the application.
Furthermore, each one is independent and its code must be able to be deployed without affecting the others. Even each of them can be written in a different programming language, since they only expose the API (a common interface, which does not care about the programming language in which the microservice is programmed below) to the rest of the microservices.
Monolithic approach vs. microservices
In order for you to really understand what we are doing with microservices, I am going to give a very simple example. Imagine that we want to make a web application, Amazon type, but easier. Users enter our website, see the products we have for sale, and when they buy an item, we manage the shipment of the product to their home.
We can access the store’s website, make purchases, etc., thanks to a server, a machine that is executing the application code which eventually connects to a database to retrieve information.
When a user buys a product via the web, we show the available products, etc., the application will respond in one way or another, according to what we have programmed, but the code of the different business logics (inventory, payments, shipments), although it may be separated into different modules of the code, it is finally packaged into a single executable file. That is why it is called monolithic architecture.
If a change is made in the payment module, all the code, including the inventory and shipping modules, will have to be uploaded to production again, despite not having changed them.
Additionally, to scale the application (for example, cater to many users), copies of the application will need to be run on load balancers, which will redirect users to one site or another, depending on whether the system is heavily saturated. In this case, the entire application will have to be replicated, even if only the payment module concentrates the overhead.
But on the other hand, if the application is not very complex, the upload will be simple and easy to manage, since in this case we are talking about a single executable file.
Instead of having a single executable, each component is an executable by itself, and the services communicate with each other through calls.
In this case we also have a microservice that implements the web interface with which users interact and some logic below to call the payments, inventory and shipments microservice when necessary.
As benefits with respect to the previous approach we have to:
- Each microservice can be deployed independently: a change in the inventory module will not affect the others, we will only have to upload that module.
- It is easy to understand, since the business logic is well separated.
- It facilitates the management of multifunctional and autonomous teams.
By itself, each microservice is multi-functional: it has a database, backend, etc. part, in addition to being independent from the others. We can form cross-functional teams that handle multiple microservices, scaling the development process more easily.
- It is easier to scale at the software level, since instead of replicating the entire application and managing it with balancers, we will replicate the microservices that have the most load.
And since an image is worth a thousand words, this would be a summary of the comments:
So do I switch to microservices or not?
A microservices architecture may seem very beneficial, but like everything, it has its pros and cons. Like any software architecture.
Also, the widespread idea that continuous deployment or continuous delivery can only be achieved with microservices is not real.
The thing to keep in mind is that microservices introduce complexity, which you will have to manage.
You have to make a great effort in automatic deployments (if you have 300 microservices you cannot be deploying each one by hand), monitoring (if one fails, you cannot go looking one by one to see what happens), manage failures, consistency of data, testing strategy and more factors introduced by distributed systems.
On the other hand, I would say that if your software is very simple, don’t go into a microservices approach. But, if it becomes too complex to manage and is worth investing effort in, go ahead. Very large companies have done it.
There may be people who develop a new application using microservices, but the approach I have come across the most is from companies that have seen that managing their software as a “monolith” is so complex, that they have started separating the application into microservices or managing developments new that way.
In this case, I would advise evolving the architecture towards microservices, but little by little, maintaining a monolithic part, combined with certain separate microservices (the most urgent areas of the application that need to be decoupled).
Don’t forget, analyze the situation, you do not want to implement microservices because it is “what is taking now.” There are many types of architectures and solutions, the question is to see what is best for us at all times.