EN 
PT 
ES 
What are microservices? Microservices are an architectural style in which the application is built as a set of small, independent services, each one responsible for a part of the business and talking to the others through defined interfaces, usually APIs. Each service is developed, deployed and scaled on its own.
The rest of this text covers what most material leaves out: what that choice costs once it is in place, and when it does not pay off.
What is meant by microservices
The change from the earlier model is this: software stopped being a single piece.
This means that, with the emergence of microservices within information technology, software is no longer designed to be monolithic. Before this innovation, which is the central theme of this article, most software was built in a broad way, as if it were a large service, where small parts were integrated with each other.
But in the old model, there was not only integration between the parties, but also a relationship of interdependence, so that the results of projects carried out by the team were often harmed by this issue.
It turns out that, with the advancement of the sector, the market realized that it is much more advantageous in several aspects, for software to be created in a separate way, with the independent creation of each part of a system.
These parts still communicate with each other, obviously, otherwise it would be unfeasible. However, they are independent and can be performed as such or as part of the same service.
Furthermore, as microservices are independent, this has improved the way updates and improvements are implemented in IT systems. Because, you can carry out updates for each part, without interfering with the others.
Thus, an update that could previously improve a certain software function, but would cause problems with another function, is now no longer a problem. Each part works autonomously, which allows broad use of services without concerns about incompatibility, updates, general breakdowns and other issues.
This means that different stages of your team's work can be carried out separately, but joined together if necessary. Furthermore, at the same time that everything is connected to each other, there is no dependency relationship, meaning that the work can be carried out much more freely.
Role of IT microservices in your team
After delving a little deeper into the concept of microservices, you may be thinking about ways that this new systems concept can improve your team's performance.
To know how this can happen, it is necessary to look at the various advantages that this innovation brings to the IT world.
Initially, one of the great advantages is scalability, as microservices allow additions and modifications to the services that make up a system, without failures or compromising joint functions.
This means your team's work is not affected every time a part of the software you use needs to be updated. This way, there is no loss of time or delays in the development of work in progress, as there is no need to close activities for a period while improvements are made.
This is crucial, especially in large projects, as the loss of one day of work, no matter how small it may seem, can delay the entire delivery schedule and cause financial losses.
And when you work with technological systems, you never know when you will need to make repairs, updates and improvements to current systems. This is because, every day there are new demands and compatibility needs that need to be followed to serve the business, and obtain the best development of the team and the work generated.
Furthermore, microservices are much lighter, so making modifications or implementations becomes a much simpler and more agile task. Once again, this improves the performance of the team that does not have the flow interrupted or delayed.
Furthermore, your team will be able to use different technologies from the independent parts of microservices. This is because, precisely because there is no interdependence, they can use different programming without the occurrence of conflicts between the systems.
This part is essential for each individual to work autonomously, but in line with the project and the needs of the entire work.
Another way in which this innovation can make your team more efficient is in relation to building systems. When systems are built in small parts, the result is obtained more easily and efficiently. Because, after building, they just need to be joined together to work together.
However, for this to work fully and to actually play a fundamental role in improving your IT team, microservices need to have efficient forms of communicability.
To do this, you need to have microservices developed by high-level professionals, with tools that have a great impact within the IT team and that are really efficient.
Which is simple to find as long as you consider quality and experience as crucial factors when hiring companies that provide microservices and services in general.
Microservice and monolith: the difference that matters
In a monolith, the application is a single codebase that ships all at once. Changing one function means redeploying the whole thing, and scaling one part means scaling everything.
With microservices, each service ships on its own and scales on its own. The catalog can get ten times the hardware on Black Friday while the sign-up service gets none.
The difference that actually decides, though, is not technical. It is who can ship without asking whose permission. In a monolith, two teams touching the same code have to agree on when it goes out. Split into services, each one ships at its own pace. A microservice is an organizational boundary before it is a technical one, which is why it solves little in a company with a single team.
When microservices are not worth it
Four situations where the numbers do not add up:
- A small team. More services than people means everyone looks after everything. That is the monolith again, now with network latency in the middle.
- No deployment automation. Ten services are ten pipelines to maintain. Without that in place first, the gain in autonomy turns into manual work multiplied.
- A domain you do not understand yet. A wrong boundary between modules gets fixed by refactoring. A wrong boundary between services gets fixed with data migration and an agreement between teams, and that is far more expensive.
- Volume the monolith handles fine. Independent scaling only pays off when the parts grow at different rates.
Teams that regret microservices almost never regret the technology. They regret where they drew the boundaries.
The cost that shows up later: visibility
In a monolith, when something breaks, the stack trace says where. The request was born and died in the same process.
Spread across eleven services, "it is slow" stops having an address. The user waits 8 seconds, every service answers within an acceptable time, and no dashboard shows where that time went. That is the bill that arrives after the migration, and it almost never makes it into the decision to migrate.
That is exactly the problem distributed tracing exists to solve. It is worth reading what observability is before going any further, because moving to microservices without settling it trades a delivery problem for a diagnosis problem.
How to decide
The question is not whether microservices are better. It is whether the cost of running several services is lower than the cost of keeping teams waiting on each other. In a company with one team and steady volume, it rarely is.
Integrity-UX looks after the layer that decision leaves behind: monitoring of infrastructure and services, with alerting and incident response. To find out what your environment cannot see today, talk to us.
This content was produced by the Integrity-UX team, an IT consultancy specializing in infrastructure, cloud, security and business continuity for medium and large companies.
Source: Martin Fowler, Microservices.
