Importance of Transport Independence in Microservices
One of the main features of microservices is their ability to communicate with each other but this feature does not require that the microservices know each other. Microservices should be a black box and stateless. Explicit coupling is the result of ignoring these two concepts. There are many strong criticisms of microservice architecture.
One of the strongest and most popular criticisms of micro service architecture is that this architectural approach is more complex than other architectural approaches and a less manageable version of traditional monolithic architectures.
In fact, this criticism contains an illusion. In my opinion, Messages over the network are nothing more than elaborate remote procedure calls. For this reason, systems defended by this argument are a mess of dependencies. Any system with this kind of dependency complexity is called a distributed monolith, not a microservice.
In fact, the most important reason that arises from this problem is the belief that the identity problem is important. In reality, the only thing that needs to be known is that only the address of the microservice you want to send a message to should be known as the identity information when constructing a communication model in microservices. This is common in systems where the entire communication model is built on HTTP calls because this communication model has to know not only the message but also the receiver to whom the message will be sent.
In fact, The world is a universe where it sends and receives messages for every microservice but they do not have any knowledge about the sender and the receiver.
You may think it’s impossible, but rest assured it’s not impossible. You can use the configuration system of the transport system for messages in microservices. But ultimately, that’s merely an implementation detail. The key idea is that microservices don’t need to know about search other, how messages are transported from one microservice to another, or how many other microservices see the messages. This is the idea of transport independence and using it means your microservices can remain fully decoupled from each other. Transport independence means you can defer consideration of practical networking questions. This perspective is actually one of the main ingredients of the nature of microservices. It also makes possible the false but really useful assumption that any microservice can receive and send any message.
Can you imagine how usable it would be? It allows you to separate the operations of how messages are transported from the behavior of microservices.
You can map messages from the message language to microservices in a completely flexible way with transport independence. It allows you to design new microservices for you without being affected by the design or structure of other microservices.
As it is known, microservices should be disposable.
Assuming that any system can see any message, you have the freedom to design the next message structures even in the early stages of your design. Thus, it will be easier and faster to add new services to your system. You will also avoid the misconception that microservices have identities and get rid of a huge dependency by using messages.
You can use pattern matching to correlate messages and services.
Physical transport and implementation of messages is not something to be neglect, especially in large systems. On the contrary, it is a real engineering problem in the true sense of the word. The only condition for having all this freedom is that microservices must be written with transport independence in mind. For this, you will need a completely abstract transport mechanism. Once you have the ability to change the way your messages are distributed, you can create your communication model using request/response patterns, publish/subscribe patterns, actor patterns, or any other variant of these patterns without any dependencies.
When designing a distributed and large system, building the entire structure on the HTTP call is actually a crazy gamble that you are sure to lose in the end. your system will move away from the basic principles and benefits of microservice architecture over time. You can be sure that you will only have a dispersed monolith after a while.
In conclusion,
If you use the wrong methods to get rid of your monolith architecture without understanding the basic philosophy behind microservices, you will end up with a distributed monolith system at best. A distributed monolith system is more costly than a traditional monolith system.
Useful Links
https://www.redhat.com/en/topics/integration/what-is-event-driven-architecture
https://livebook.manning.com/book/microservices-patterns/chapter-3/
