In monolithic systems, many projects fail to be successful in the move to microservices architecture just because of problems in the communication layer. Of course, when we talk about containers, distributed applications, and business domain partitioning, some terms may amaze you—these terms are latency and data translation.
Communication in a monolithic application is made up of internal components, such as methods, functions, attributes, and parameters. In this ecosystem, latency and data translation are irrelevant. In the world of microservices, they are topics that must be thoroughly analyzed.
There are two methods of communication between microservices:
- Synchronous
- Asynchronous
It is important to understand how each of these forms works. Let's see how:
One-to-One | One-to-Many | |
Synchronous | Request/response | - |
Asynchronous | Notification | Publish/subscribe |
Request/async response | Publish/async responses |
Have a look at the preceding table; the type of communication adopted will vary according to the need of the domain. For direct and sequential systems, a synchronous communication approach may be more appropriate. In the case of tasks that do not need an immediate response, the asynchronous approach can be the most appropriate.
When it comes to the communication layer between microservices, synchronous is certainly the most widely used approach. Within this topic, some protocols are well known and others less so. The range of direct protocols is as follows:
- HTTP
- TCP
- WebSockets
- Sockets
- RPC
- SOAP
Arguably, the most commonly implemented is HTTP. Many microservices use HTTP to communicate with each other, where as the HTTP is typically used with JSON.
The problem with this approach is that, with HTTP, JSON can generate an unwanted processing time to send and translate the information. Some teams that use JSON with HTTP only adopt the keep alive strategy for app-to-app communication and conventional connections to APIs.
When it comes to HTTP, API with JSON is practically normative. However, for internal communication between microservices, this is quite questionable. A good approach, in this case, considering problems of latency and data translation, is the use of binary traffic for communication between microservices.
There are some very interesting options for this approach: Avro, Protocol Buffer with CPRM, and Thrift are some examples. Another important point is that with binary we are not tied to any specific technology, and changing the communication interface with this technology is extremely simple.
In some direct communications between microservices, timing may be important, but there are other times where the process can simply be asynchronous; there's no need for an immediate response or confirmation of success, all that is required is to simply run a task. For this approach, the message broker is just perfect.
Some software applications appear a good choice for message brokers, such as RabbitMQ, ActiveMQ, ZeroMQ, Kafka, and Redis. Each of these options has its own peculiarities, some are faster, others are more resilient. Again, the business setting is going to determine which technology is used.