Chapter 21 — Microservice Communication

Communication Protocols

The following list is the previous chapters of this series:

Structure

RPC
REST
AMQP

Communication Protocols

In this section, we will delve into the RPC, REST, and AMQP (Advanced Message Queuing Protocol) protocols, all of which represent prevalent methods for facilitating communication between microservices. The selection of one over the other hinges upon the precise needs of the application and the design preferences under consideration.

Each protocol carries its own set of advantages and drawbacks. Consequently, making the right choice hinges on selecting the one that aligns most closely with the specific requirements of your microservices architecture.

Throughout this section we will analyze each of them, reviewing their main characteristics and their contributions to communication between microservices.

RPC

The acronym RPC stands for “Remote Procedure Call”, which can be described as a protocol enabling one microservice to invoke a function or method in another microservice, simulating a local procedure call. The primary objective is to make this remote call as seamless and transparent as possible. RPC can be implemented through a range of transport protocols, including but not limited to HTTP/HTTPS, gRPC, RMI (Remote Method Invocation), and others.

RPC is frequently employed in scenarios that demand high-performance, synchronous communication between microservices. An exemplar of RPC implementation is gRPC, which utilizes the HTTP/2 protocol for communication, making it a popular choice in this context.

Key RPC Components

RPC Client The client is the application that initiates the remote call. In the context of microservices, the RPC client is typically a microservice that needs to invoke a function or method in another microservice.
RPC Server The server is the application or microservice that responds to remote calls. Provides an implementation of the function or method that the client wants to invoke.
RPC Interface The RPC interface defines the procedures or functions that are available to be called remotely. These procedures are defined in an interface description language (IDL) and are shared between the client and the server to ensure that both parties understand how to communicate.
RPC Protocol The RPC protocol defines how calls and responses are packaged and transmitted between the client and the server. Some common RPC protocols include Google’s Protocol Buffer (gRPC) being one of the most common, Java RMI (Remote Method Invocation) and CORBA (Common Object Request Broker Architecture).

Pros and Cons

Pros

Transparency RPC provides the illusion of local calls, simplifying the developer’s experience by abstracting away the intricacies of network communication when working with remote calls.
Efficiency RPC, characterized by its synchronous and procedure-oriented communication, typically demonstrates efficiency in terms of performance and resource utilization.
Language-Agnostic The majority of RPC systems facilitate the use of distinct programming languages for clients and servers, streamlining the integration of heterogeneous components and enhancing versatility.

Cons

Lack of Flexibility RPC, owing to its procedural orientation, may exhibit less flexibility compared to alternative approaches like REST. Consequently, it might not be the optimal choice for situations demanding a high level of adaptability.
Blocking In synchronous RPC communication, the client must await a response from the server, potentially leading to blocking if the server experiences delays in responding.
Coupling When not used judiciously, RPC has the potential to introduce coupling between the client and the server, which can impede the independent evolution of microservices.

In summary, RPC is a protocol that streamlines communication among distributed applications through remote procedure calls. While it provides transparency and efficiency, it’s important to consider potential limitations in terms of flexibility and coupling. Therefore, your selection should be contingent on the precise system requirements and design considerations at hand.

You can find a couple of good examples implementing gRPC with golang in the following articles written by me:

Implementing gRPC with Golang

Server streaming

blog.devgenius.io

Implementing gRPC with Golang

Unary server-client

medium.com

AMQP

The abbreviation AMQP stands for “Advanced Message Queuing Protocol.” It can be described as a messaging protocol employed for asynchronous communication among microservices, achieved through the exchange of messages within queues. AMQP offers an advanced messaging model characterized by features such as message queuing, adaptable routing, and delivery confirmation.

AMQP finds its primary utility in scenarios necessitating resilient and fault-tolerant asynchronous communication. It excels in managing events, handling background processing tasks, and facilitating communication among microservices that don’t demand immediate responses.

AMQP is a specific protocol that defines how clients and servers should communicate to send and receive messages asynchronously. Some popular implementations of AMQP include RabbitMQ and Apache Qpid.

Key AMQP Components

Producer The producer serves as the entity responsible for dispatching messages to a message queue or exchange within the system. This entity can take the form of a microservice, an application, or a system tasked with generating messages for subsequent processing.
Consumer The consumer represents the entity responsible for receiving and processing messages from a message queue or exchange. Multiple consumers can exist, each designed to efficiently handle and process messages as they are received.
Message Queue A message queue serves as a designated entry point where producers deposit messages, and from which consumers retrieve them. Messages within a queue are dispatched in the sequence of their arrival and can be processed by one or more consumers.
Exchange An exchange is a component that acts as a message router. Producers send messages to an exchange, and the exchange decides how and where the messages should be delivered to the appropriate message queues based on routing rules.
AMQP Broker The broker stands as the central component in the AMQP system. Its role encompasses the management of message queues, exchanges, routing rules, and the facilitation of message delivery between producers and consumers. Noteworthy examples of popular AMQP brokers include RabbitMQ and Apache Qpid.

Pros and Cons

Pross

Delivery guarantee AMQP ensures a dependable message delivery guarantee, assuring that messages remain intact and are conveyed precisely once, even in the event of failures.
Asynchronous communication It enables asynchronous communication between applications and microservices, fostering the separation of processing logic and autonomy among system components.
Scalability Systems employing AMQP exhibit high scalability, allowing you to expand capacity by incorporating additional producers, consumers, or brokers as your workload increases.
Flexible routing Thanks to configurable exchanges and routing rules, AMQP offers substantial flexibility in the distribution of messages to message queues and consumers.
Security AMQP boasts robust security mechanisms, encompassing authentication and encryption, to safeguard the integrity and confidentiality of transmitted messages.
Interoperability AMQP stands as a widely embraced open standard, affording you the capability to employ various implementations of AMQP brokers and clients to ensure seamless interoperability.

Cons

Complexity The configuration and administration of an AMQP system can prove intricate, particularly when contrasted with more straightforward approaches like REST. It necessitates a deeper understanding of message queues, exchanges, and routing rules.
Low latency performance In scenarios demanding low-latency and synchronous communication, AMQP may not be the optimal choice, as asynchronous communication inherently introduces some latency owing to message queuing and routing processes.
Protocol Overload AMQP has some protocol overhead due to message serialization and communication through brokers, which can affect performance in applications that require high data transfer rates.
Broker dependency Systems relying on AMQP are dependent on messaging brokers for their functionality. Any issues encountered by the broker could potentially impact the availability of communication.

In short, AMQP is a messaging protocol that enables efficient and reliable asynchronous communication between applications and microservices. It features critical features such as guaranteed delivery, flexible routing, and scalability, making it a solid choice for various messaging and communication applications in distributed systems. However, it is crucial to consider that the choice of AMQP should be based on the specific requirements of the project and the understanding necessary for its configuration and management. This protocol is especially beneficial in applications that demand delivery reliability, scalability, and efficient asynchronous communication.

You can find a good example in the following article (written by me):

Tutorial: AMQP with Golang

Implementing RabbitMQ with Golang

medium.com

REST

REST, short for “Representational State Transfer,” can be defined as an architectural style for designing web communication systems and distributed applications. Unlike specific protocols such as AMQP or gRPC, REST constitutes a set of design principles centered around simplicity, scalability, and interoperability in system communication.

Key REST Characteristics

Resources Within the REST architectural style, everything is conceptualized as a resource — an identifiable entity with a state. These resources are uniquely identified by URIs (Uniform Resource Identifiers), similar to URLs on the web.
HTTP Operations REST uses standard HTTP verbs to perform operations on resources. The main verbs are GET (to retrieve data), POST (to create resources), PUT (to update resources), and DELETE (to delete resources).
State Resources may possess a state that can be depicted in formats such as JSON or XML. Clients have the capability to access and modify the state of resources through HTTP operations.
Stateless REST is “stateless”, which means that each HTTP request contains all the information necessary to understand it. No state information is stored on the server between requests. This simplifies scalability and redundancy.
Uniform Interface REST promotes a uniform interface that makes applications easy to understand and use. This includes consistent use of URIs, HTTP verbs, and content types.
Client-server system REST adheres to the principle of a clear separation between the client and server. The server’s role is to store and manage resources, while the client handles presentation and user interaction.

Pros and Cons

Pros

Simplicity REST is known for its simplicity, which enhances comprehension and facilitates development and adoption.
Interoperability REST applications, thanks to their adherence to web standards like HTTP and URIs, offer high interoperability, allowing access from diverse platforms and programming languages.
Scalability RESTful applications benefit from a stateless architecture, coupled with the straightforward incorporation of caches on both the client and server sides, facilitating their scalability.
Wide adoption REST offers extensive adoption and compatibility with the majority of web technologies and frameworks, making it a preferred choice in the development community.

Cons

Limited on complex operations REST is most adept at handling straightforward CRUD (Create, Read, Update, Delete) operations and may prove less ideal for intricate operations or specialized actions.
Synchronous Communication In conventional REST communication, the client awaits a response from the server, a process that may not be ideal in applications dealing with high latency or intensive workloads.
Flexible specification REST is flexible in its implementation, which can lead to a lack of standardization in some areas.

REST serves as a straightforward and extensively embraced architectural framework for communication within web applications and distributed systems. Its simplicity, scalability, and ease of implementation render it appealing for a multitude of applications. However, it is essential to carefully assess project requirements when deciding whether REST is the right choice or when considering whether a more intricate approach like AMQP might be a more fitting alternative.

Next readings …

Wait for Chapter 22 “Security and Microservices”, which will be published in the coming days.