Microservices Communications

Microservices Communications

In this tutorial, we are going to discuss Microservices Communications. We will learn definitions, communication types, and how they can use in microservices architectures in the e-commerce domain.

By the end of the article, you will learn Microservices Sync and Async Communications with patterns and practices. We will discuss RESTful APIs, gRPC, and Message Broker systems.

When we are talking about Monolithic applications, we said that the communication in Monolithic applications is inter-process communication. So that means it is working on a single process that invokes one to another by using method calls. You just create a class and call the method inside of target module. All running the same process.

This communication gives is very simple but at the same time components are highly coupled with each other and hard to separate and scale independently.

One of the biggest challenges when moving to the microservices-based application is changing the communication mechanism. Because microservices are distributed and microservices communicate with each other by inter-service communication on the network level.

Each microservice has its own instance and process. Therefore, services must interact using inter-service communication protocols like HTTP, gRPC, or message brokers AMQP protocol.

Since microservices are complex structures into independently developed and deployed services, we should be careful when considering communication types and manage them into design phases.

Before we design our microservices communications, we should understand communication styles, it is possible to classify them in two axes. The first step is to define communication protocol is synchronous or asynchronous.

Microservices Communication Types — Sync or Async Communication

Now we are going to discuss Microservices Communication types. Synchronous and Asynchronous Communication.

Client and services communicate with each other with many different types of communication. Mainly, those types of communications can be classified into 2 axes.

• Synchronous
• Asynchronous

Synchronous communication

Basically, we can say that Synchronous communication is using HTTP or gRPC protocol for returning sync responses. The client sends a request and waits for a response from the service. So that means client code blocks their thread until the response reach from the server.

The synchronous communication protocols can be HTTP or HTTPS. In synchronous communication, the client sends a request using HTTP protocols and waits for a response from the service.

So that means the client calls the server and blocks the client their operations. The client code will continue its task when it receives the HTTP server response. So this operation is called Synchronous communication. It has pros and cons that we should consider when we pick this way.

Asynchronous communication

Basically, In Asynchronous communication, the client sends a request but it doesn’t wait for a response from the service. So the key point here is that the client should not have blocked a thread while waiting for a response.

The most popular protocol for this Asynchronous communications is AMQP (Advanced Message Queuing Protocol). So using AMQP protocols, the client sends the message using message broker systems like Kafka and RabbitMQ queue. The message producer usually does not wait for a response. This message consumes by the subscriber systems in an async way, and no one waiting for a response suddenly.

Asynchronous communication is also divided by 2 according to implementation. Asynchronous systems can be implemented in a one-to-one(queue) mode or one-to-many (topic) mode.

In a one-to-one(queue) implementation there is a single producer and single receiver. But one-to-many (topic) implementation has Multiple receivers. Each request can be processed by zero to multiple receivers. one-to-many (topic) communications must be asynchronous.

So we will see this communication with the publish/subscribe mechanism used in patterns like Event-driven microservices architecture in the upcoming tutorials. Basically, an event-bus or message broker system is publishing events between multiple microservices, and communication provides with subscribing these events in an async way.

Apache Kafka and RabbitMQ are the best tools for these operations. As you can see that we have understood Microservices Communication types — Sync or Async Communication, And the microservice-based application will often use a combination of these 2 communication styles. So we will also design our e-commerce architecture using both communication types.

But before that, let’s elaborate on the Synchronous communication and underlying mechanism.

Microservices Synchronous Communication and Practices

As we said before, In synchronous communication, the client sends a request using HTTP protocols and waits for a response from the service. The synchronous communication protocols can be HTTP or HTTPS.

But how we can design and expose APIs with HTTP protocols for our microservices? we should focus on that point.

When we are using asynchronous request/response-based communication type, HTTP protocols and REST approaches are the most common way to use to design APIs, especially if we’re exposing APIs to the outside of the microservice cluster.

If we’re communicating between services internally within our microservices cluster, we might also use binary format communication mechanisms like gRPC. gRPC is one of the best ways to communicate for internal microservice communication, we will discuss gRPC in the upcoming sections.

E-Commerce Service Communications

Let’s check our e-commerce architecture design.

As you can see now these lines represent sync communication. And these communications will be HTTP-based RESTful APIs which will return to JSON objects. But if there is required to communicate internal microservices, its good to choose gRPC binary protocols in order to be fastest as possible.

We use different protocols for client call and internal communication even both type is sync communication. Because client request is good to be REST in order to see payloads explicitly, backend communication can be sacrificed to see payloads instead of picking the velocity of response time. gRPC is much faster than the REST.

So we can say that, if we prefer to communicate with synchronous communication, we have several options those are; HTTP protocols and REST approach. gRPC binary format communications. So let’s elaborate on these 2 approaches.

Designing HTTP based RESTful APIs for Microservices

In synchronous communication, when making request/response communication, we should use REST when designing our APIs. Its also called Restful APIs. The REST approach is following the HTTP protocol, and implements HTTP verbs like GET, POST, and PUT.

REST is the most commonly used architectural communication approach when creating APIs for our microservices. For implementing REST services, we have several options for example using Java and Sprint Boot framework or using C# with ASP.NET Core Web API services.

Anyway, we should focus on how to design our APIs for microservices. Good API design is very important in a microservices architecture because communication with data transfers happens through messages or API calls.

Designed APIs should be efficient and not be chatty communications. Because In a microservices architecture, services are designed for working independently, APIs must have well-defined documented and versioning, so updates don’t break other services.

There is 2 type of APIs when designing sync communication in a microservices architecture.

1. Public APIs which are APIs calls from the client applications.
2. Backend APIs are used for inter-service communication between backend microservices.

Public APIs, should be aligned with the client’s request. Clients can be a web browser or mobile application requests. So that means the public API should use RESTful APIs over HTTP protocol. So RESTful APIs should use JSON payloads for request-response, this will easy to check payloads and easy agreement with clients.

For the backend APIs, We need to consider network performance instead of easily readable JSON payloads. Inter-service communication can result in a lot of network traffic. For that reason, serialization speed and payload size become more important. So for the backend APIs, These protocols that support binary serialization should implement. The protocol alternatives are using gRPC or other binary protocols are mandatory.

Let’s compare the REST and gRPC protocols,

REST is using the HTTP protocol and request-response structured JSON objects. API interfaces designed based on HTTP verbs like GET-PUT-POST and DELETE.

gRPC is basically a Remote Procedure Call, that basically invokes an external system method over the binary network protocols. Payloads are not readable but it is faster than REST APIs.

RESTful API design for Microservices

In synchronous communication, when making request/response communication, we should use REST when designing our APIs. Its also called Restful APIs. The REST approach is following the HTTP protocol, and implements HTTP verbs like GET, POST, and PUT.

RESTful services are widely used in modern Web architectures. It is pretty lightweight, extensible, and simple easy develop services. We will start with REST definition and after that talk about RESTful Apis and how to design RESTFul Apis.

What is REST ?

REST (Representational State Transfer) is a service structure that enables easy and fast communication between client and server. Roy Fielding introduced and developed REST in his doctoral thesis in 2000. It was developed as an alternative to SOAP and WSDL-based Web services. REST runs on HTTP.

Compared to alternative structures, it is faster and more efficient in sending and receiving data with more basic and minimum content. REST allows applications to communicate with each other by carrying JSON data between the client and server.

Features of REST

When we look at the constraints of the REST architecture, we come across six items:

• Stateless
• Uniform Interface
• Cacheable
• Client-Server
• Layered System
• Code on Demand

I am not going to the deep insight into these features but you can consider these are the characteristics of REST services.

What is RESTful APIs?

Web services that use REST architecture are called RESTful services. RESTful systems generally communicate over HTTP protocol with HTTP methods (GET, POST, PUT, DELETE, etc.) used by Web Browsers to transfer pages.

Richardson Maturity Model

In 2008, Leonard Richardson proposed the Richardson Maturity Model for web APIs:

Level 0: Define one URI, and all operations are POST requests to this URI.
Level 1: Create separate URIs for individual resources.
Level 2: Use HTTP methods to define operations on resources.
Level 3: Use hypermedia

These are the levels of calculating the maturity of REST APIs.

How we can design Restful APIs for microservices?

We should focus on the business entities to that we expose APIs for our application. So that means we should organize our resources according to business entities and expose them properly via APIs.

Let’s think about our e-commerce application, the primary entities might be customers and orders. When creating an order, we basically send an HTTP POST request with contains customer and order detail information. And return back to the HTTP response that includes 200 OK success responses.

So how we can handle this kind of Restful API? The best practice is the resource URIs should be based on nouns (the resource) and not verbs.

For example :
https://eshop.com/orders // Correct

https://eshop.com/create-order // Wrong

So now let’s think about the e-commerce application and our Customer and Order entities, resources. So if we design HTTP methods, it should be on this table:

Since we are using the HTTP protocol, You can find Different Resources Urls are indicating HTTP verbs like get-put-post and delete.

See the table we have /customer’s main resource. and we can filter by adding /1 and /orders by following REST principles.

Microservices RESTful API Design

If we talk about the microservices design on APIs you can see the image;

In a microservices architecture, microservices don’t share the same code base and don’t share data stores. Instead of that, they communicate through APIs for data operations.

If we look at the image, the Shopping Cart service requests information about a customer from the Customer service. The Customer service retrieves data using Repository classes and returns the Customer entity model as a JSON object in an HTTP response. So this provides to the isolation of services.

What is gRPC?

gRPC (gRPC Remote Procedure Calls) is an open-source remote procedure call (RPC) system initially developed at Google. gRPC is a framework to efficiently connect services and build distributed systems.

It is focused on high performance and uses the HTTP/2 protocol to transport binary messages. It relies on the Protocol Buffers language to define service contracts. Protocol Buffers, also known as Protobuf, allow you to define the interface to be used in service to service communication regardless of the programming language.

It generates cross-platform client and server bindings for many languages. Most common usage scenarios include connecting services in microservices style architecture and connecting mobile devices, browser clients to backend services. The gRPC framework allows developers to create services that can communicate with each other efficiently and independently from their preferred programming language.

Once you define a contract with Protobuf, this contract can be used by each service to automatically generate the code that sets up the communication infrastructure. This feature simplifies the creation of service interaction and, together with high performance, makes gRPC the ideal framework for creating microservices.

How gRPC works?

In GRPC, a client application can directly call a method on a server application on a different machine like it were a local object, making it easy for you to build distributed applications and services.

As with many RPC systems, gRPC is based on the idea of defining a service that specifies methods that can be called remotely with their parameters and return types. On the server-side, the server implements this interface and runs a gRPC server to handle client calls. On the client-side, the client has a stub that provides the same methods as the server.

gRPC clients and servers can work and talk to each other in different environments, from servers to your own desktop applications, and that can be written in any language that gRPC supports. For example, you can easily create a gRPC server in Java or C# with clients in Go, Python, or Ruby.

Working with Protocol Buffers

gRPC uses Protocol Buffers by Default. Protocol Buffers are Google’s open-source mechanism for serializing structured data.

When working with protocol buffers, the first step is to define the structure of the data you want to serialize in a proto file: this is an ordinary text file with the extension .proto. The protocol buffer data is structured as messages where each message is a small logical information record containing a series of name-value pairs called fields.

Once you’ve determined your data structures, you use the protocol buffer compiler protocol to create data access classes in the languages you prefer from your protocol definition.

You can find the whole language guide in google’s official documentation of protocol buffer language. Let me add the link below.
https://developers.google.com/protocol-buffers/docs/overview

Advantages of gRPC

General advantages of gRPC:

• Using HTTP / 2

These differences of HTTP / 2 provide 30–40% more performance. In addition, since gRPC uses binary serialization, it needs both more performance and less bandwidth than JSON serialization.

• Higher performance and less bandwidth usage than json with binary serialization
• Supporting a wide audience with multi-language / platform support
• Open Source and the powerful community behind it
• Supports Bi-directional Streaming operations
• Support SSL / TLS usage
• Supports many Authentication methods