Relationship between microservices

Question

Even after reading and watching various content on microservices I still have a flea behind my ear that won’t leave me alone.

Let’s consider microservices running perfectly, each one with its DB, and at a given time I need to relate the data of each, or would be mistaken?

For example, I have a microservice that processes purchase orders, a microservice that controls inventory and a microservice of customers.

Basically when I need to make a report to display the amount of purchase per customer with their respective stock movements per product, I don’t know, something like.

If you want to imagine a similar scenario, I just need to understand how I would solve this situation with microservices? In a monolithic scenario is a slap and would be solved.

Answer 1

One of the reasons you still don’t understand the concept is that you still think of it as a macroservice. Inventory Control is a microservice?!?!

There is no size definition for a microservice, but it certainly has a single responsibility. Ordering purchases may seem like it’s unique, but it’s not. Customers may already perhaps be a microservice.

And yes, in fact the data needs to relate at some point. The two basic strategies are:

• each microservice has all the data needed to perform what it needs, getting notifications from other microservices whenever something has been updated there, so you have it all "fresh";
• microservice is a coordinator who makes every relationship in the moment that needs it.

The first generates brutal inefficiency because almost every update is wasted. For all of this to work, things need to be more plastered than a monolithic environment, which is a contradiction because they say that microservice makes maintenance easier. Yes, it is true, it facilitates, because it practically prohibits doing much. The most famous cases of microservices have very little important maintenance in the system.

The most famous cases are systems maintained by thousands of programs. Most likely far more than would be needed in a monolithic system.

Why do you have this image? Because almost always only bad programmers adopt complex solutions when simple solved. And microservice is almost always the complex solution that people don’t need.

Imagine a microservice request report received update whenever something has changed in the orders or things related to the requests that are in the report, all of which need to be updated everywhere, how much waste occurs between you needing the report over and over.

Imagine how complicated it is to tinker with certain services knowing that it can have many uses that you have no control using that you promised to provide?

The second way is not used that much, and it has even been avoided, and is to create in your application what the relational database has always done optimally, when one knows how to use it. If the person does not know how to use DB correctly, how will it play what DB does in your application?

You turn a problem that should be specific, and this is easier to solve, into a generic problem, which is more difficult.

There are legitimate reasons to adopt this architecture, and one of them is that you already had a generic problem anyway. Another is to be isolated naturally.

Completion

Is it extremely difficult to do it correctly? Yes, it is. It is considered the most difficult problem in computing.

So the answer is that you wouldn’t solve this with microservice, it shouldn’t be called a solution, it’s an extra problem that you don’t need to have.

Microservices can work better when they exist in a natural way, that is, it is all isolated even, it does not have many relationships. The problems you are setting as an example do not need and do not work well as microservices. Even if people do it, it’s just for fashion, it’s just because they saw other people doing it and they think it’s sexy to do it too, they feel good to do something like that. Now turn your eyes up, give scroll if necessary, and look at the image again. In general bad programmers don’t realize they’re like that.

There are legitimate problems to use this technique, but they are extremely rare and the overwhelming majority of programmers will never come close to a problem like this.

This site is one of the 30 most accessed in the world and does not need it. Wikipedia, Instagram and others do not. I know the world of Erps and none ever needed it.

Adoption tends to be more for political reasons than for technical ones (the team wants it on the curriculum, they want to be fashionable, or there are fights between the various parts of the team).

That’s what almost every programmer needs to know about it. If by chance the person needs to do something with microservice properly, where it really makes sense, they will be very good at computing as a whole and will work in a huge team with similar qualification. So it’s good to know a little, but almost no one needs to actually learn how to do.

If you have a huge team, if you have a well qualified team, really, if you have people who don’t follow fashions, who only become adept at something with evidence that will be better, if it’s all right, it’s almost guaranteed that this team will not adopt microservices architecture (can adopt some point microservice, authentication for example).

I know it generates controversy, but yes, I’m saying that most of the people (not all) who are adopting this architecture are incompetent by definition.

For more details: How to integrate microservices?.