Micro-service and its Context
Context: The setting in which a word or statement appears that determines its meaning. Statements about a model can only be understood in a context.
Why Micro-services?
We all know that how micro-services become a popular model in distributed systems which allow us to decouple a complex logic into a set of small logics. In simple words chunking a large system to into small services. You might wonder why it is required to have set of small services instead of a cohesive system. Because it allows us to focus on small logics individually and maintain them separately.
This can avoid a significant amount of distraction and increase the autonomy of developers. For example, in an online shopping system, we could have services like Suggestion service and Purchasing service. You can see by mean of their names they have a bounded context to work on.
At runtime, if there is something needs to change in Suggestion service, it can be individually done without causing much trouble interference with the Purchasing service. Not only that, assume a scenario where users tend to search more than they do purchases, in order to keep the quality of service and quality of experience we could scale only Suggestion service to cope requests. The beauty of micro-services is we could scale only Suggestion service efficiently with available resources without doing any changes to the Purchasing service.
Compared to Monolithic Architecture
In traditional monolithic architecture if want to scale the Suggestion service we also had to scale the Purchasing service as well. Because in that architecture those components come as a single unit of the program. This leads to inefficient use of resources and micro-service architecture address this problem to some extent.
But does micro-services really good as we think? Do we really need to embrace this new architecture into all of our legacy systems? The answer is no. It is not effective or efficient to use something only because it is new or trending. You need to know your purpose of using it and possible outcomes.
As I mentioned earlier here we are focusing on set small sub-systems, which interact with each other to achieve a common goal. In micro-services, the problem is this interaction. Because one of the advantages of micro-services is autonomy which let developers come up with different solutions in their own systems. Different mechanisms, different protocols or even they might not use the same exact terminology in development. In order to communicate between these services, they need to have an agreement between services, some kind of knowledge what other service is providing.
Here A and B are micro-services communicating in both directions. That means A and B has to know about each other, regarding their context. A needs to have a knowledge of B’s context in order to translate b messages and vice versa. We consider A and B as partners.
But when it comes to communication between A and C, A does not need to worry about C’s context since C is the one who consumes A’s messages. C needs to have some idea about A’s context. It is kind of a dependency that C has to follow the rules that have been used by A (C conforms A). So here C has less autonomy within its context.
Context is a key component in Domain Driven Design which is vital to understand it to come up with a stable and unambiguous representation. Get to know about your context, use it wisely :).
In future articles, I will be discussing more on micro-services, especially about the best practices and their evolvement.
References
