Hi Leonardo.

Maybe my experience is different, but as far as I have seen, having microservices does not imply better scalability by itself.

Sometimes, with the right architecture, monoliths can scale well better with even simpler code; basically because many database engines do that task very well.

The biggest problem that I have experienced with bad designed microservices, about performance, is that because they do not have the right decoupling, they start asking for data on the other, latencies start to accumulate, and response times accumulate. Those kinds of microservices, in addition to scaling very badly, also present a very poor performance even in the most small setups.

But I did not want to focus on that in this article, there is a lot about it to explain, and a lot more about microservices. Instead, I wanted to focus on a very simple and small rule: make your deployments really independent. It by itself does not solve every problem, but to achieve that you need to solve many things. For example, when there is too much coupling between microservices (the one that starts composing latencies), it is very difficult to do an independent deployment. It is very likely that the deployment of any microservice might break another one.

I just remembering that the worst-case scenario that I have ever seen about that was a system converted from monolith to microservices, and just for the logging, passing from less that 1 second to more than one hour (of course, the connection was timed out long before that) .

So, that is why I want people to focus on independent deployability. (BTW, also because the creators of the technique were also looking for that kind of scalability: team scalability) Because if not, you do not have microservices, you have a big distributed monolith. Which indeed is harder to maintain.

BTW: Well crafted microservices are easier to maintain than big monoliths. I had some experience with them and they are delightful. I hope to explain how they work in later articles.