This blog mainly talks about the anti-patterns of building microservice architecture systems.
A microservice architecture helps a lot in many aspects. Readability, Maintainability, scalability, separation of concerns, and many more.
On the other hand, these pros might turn into cons if some anti-patterns are applied in a microservice architecture and it would be very difficult to maintain.
What does anti-pattern mean?
In software engineering and computer science, an anti-pattern is a term that describes how not to solve repetitive recurring issues in your codebase. Therefore they are always considered to be bad practices in the design of systems.
Different Microservices architecture anti-patterns.
1. Distributed Monolithic systems.
This is an anti-pattern that I have experience working with.
A monolithic app means a system that encapsulates the whole logic of the app in one unit or codebase.
One of the mistakes some people do is distributing the logic of that big monolithic app into several small monolithic apps and calling it a microservice architecture.
The fact is these small monolithic apps will eventually chat with others to achieve how the big monolithic app was working.
Any small change in one of these monolithic apps will cause the saga to break. And a change in other systems will be required, and that defeats the purpose of microservice architecture.
2. Cohesion chaos and coupling.
Cohesion in microservice architecture means the amount of how components of a single entity are tied together.
With that being said, a microservice should not care about the components of other entities.
This anti-pattern arises when unrelated components or functionalities are constantly being added to a specific microservice.
3. Dependency distortion.
This anti-pattern also arises when all of the microservices should be deployed in a specific order, otherwise, the saga and the chattiness between the microservices will break.
This is caused by the separation of concerns as well.
4. Shared schemas and datastores.
This is an anti-pattern that occurs when multiple microservices are connected to the same db.
For example, if one microservice needs to change a specific schema due to its internal logic, the microservice that is also connected to that database should adapt to the corresponding change.
4. Actions redundancy.
Action redundancy occurs when there are some functionalities that are occurring in each microservice.
Suppose that, in order for an action to start a saga in the microservices, the user who is doing the action should be authenticated. For that matter, the user should be authenticated once.
Having an API gateway becomes very handy in such situations to centralize shared logic between microservices and also to orchestrate the events between them.
Conclusion
Understanding microservice architecture and its anti-patterns are very important. A lot of complexity might be added trying to apply them without thinking of the overall design of how they should be built.
Top comments (4)
I don't know much about Microservices. But I agree with one of your opinions that many people apply something without enough knowledge or investigation. it would be a disaster for projects.
I also had like that experience. I used
Reduxfor state managing, and there was getting a lot of redundancy code. three action functions per API. I thought that others also had the same issue. someday, I saw a conference video on youtube and he said that in the video, "Redux is not just a library, it's a messaging system.". After watching the video, I thought that knowing the essentials is important before diving into something. Anyways, thank you for the good post :)I agree with you mate. Thank you for that supportive example.
Is this mostly a newbie issue (not understanding microservice architecture and anti patterns well) or more like a habit that can be met at any skill level?
It is a combination of both. People who have solid experience in microservices tend to avoid these patterns from the beginning.