Communication in a Microservice Platform

In the past few years, there has been a shift from monolith architecture to microservice architecture (find out more about this in our blog on iPaaS). Apio was built as a microservice system, which means that a lot of its parts are decoupled into different services. 

How to communicate information in a microservice platform

A microservices-based application is a distributed system running on multiple services, sometimes across multiple servers. Each service instance is typically a process. Therefore, services must interact using an inter-process communication protocol such as HTTP, AMQP, or a binary protocol like TCP, depending on the nature of each service. The most popular question that comes up when building a microservice application is “what is the best tool to use when trying to communicate between nodes in the application?”

The microservice community promotes the ideology of keeping each service as decoupled as possible i. e. each service should hold its own data and its own domain logic. Some microservices prefer using REST communications over the more complex protocols like websocket and event driven communication. The commonly used protocols are HTTP request/response, and asynchronous messaging when trying to send out multiple requests over several microservices. The image below shows three ways in which data can be communicated between different nodes in an application.

Synchronous: HTTP is a synchronous protocol. Here the client sends a request and waits for a response from the service. The main point here that points to synchronous behaviour is that the HTTP protocol is synchronous and the client code can only continue executing after it receives the HTTP server response.

Asynchronous: There are protocols like AMQP (a protocol supported by many operating systems and cloud environments) which uses asynchronous messages. The client code doesn't wait for a response, rather it sends the message to a RabbitMQ queue or any other message broker. The key point here is that the client should not be able to block a thread while waiting for a response from the server.

Apio and its communication protocol‍

Communication between nodes in the system must occur at the network layer. Apio uses two distinct communication protocols when sending and receiving data across several nodes:

Communication via websocket: Here communication is carried out between the browser and the services using a secured websocket channel to send binary messages to whichever node is specified in the websocket connection.

Communication via gRPC: gRPC is a recursive acronym for remote procedure call that can run in any environment built in its supported languages. Here communication occurs between the servers by sending serialised messages from one node to another node or one node to multiple other nodes.

What is the best tool to use when trying to communicate between nodes in a microservice system?

There are many answers to this question but it depends on a number of factors, some of which are:

• The application being built
• The resources available for the application
• The application team’s agreed upon “architectural pattern”

In conclusion, there is no right or wrong way to carry out the communication between services. As long as the underlying principles are adhered to, then the application can be designed in any way that is flexible enough for the developer to maintain.

‍

Photo Credits

Photo by Farzad Nazifi on Unsplash