API

The backbone of a robust microservices architecture

In recent days, before implementing microservices, it has always been asked as what is the correct way of communication between two microservices architecture, since the microservices are adopted by most of the industries so the perfect solution for the above question is in great demand.

According to James Lewis and Martin Fowler, there are two types of communication protocols:

1. HTTP request response with host APIs


2. Lightweight messaging.


 

The right approach to implement the process is to agree with the reality that requires to apply both synchronous and asynchronous patterns in the service interactions, and the right thing to concentrate on is to know when and where to implement which one out of two. In some cases, it aids to minimize the use of the protocol when modeling systems of microservices. One can use asynchronous interactions instead of HTTP protocol, just as utilizing synchronous interactions instead of a message bus.

There are also few other approaches to these similar kinds of systems designs out there. Domain-Driven Design (DDD) – previously designed to reach the height of object-oriented programming and also an enormous revival in fame in the microservices movement. It provides an implementation of the aggressive approach in modeling of a complex network of software systems, with its “context mapping” which is specifically useful in this regard.

Alan Kay who is considered to be one of the legends in the IT industry once stated on the concept of object-oriented programming, his exacts words were:

“I am sorry that I long ago coined the term 'objects' for this topic because it gets many people to focus on the lesser idea. The big idea is 'messaging’. The key to making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be”

In addition to the importance of inter-service communication, it is also identified that more emphasis requires to be placed on the arrows in whiteboard flowcharts than on the boxes. To gain a better understanding, in a simpler way to classify the interactions that really occurred between services. Generally, there are three types of interactions:

Here’s a simple relationship model between Query, Command and event interactions through a juice order

Query: “How much is it for an orange juice?”

Command: “I would like to order an orange juice, please” [pays]

Event: “Sir, your orange juice is ready!”

The protocol is picturized in this example. Both the query and command could have occurred in real life, or on a mobile app. Similarly, the event could have been called off in the juice parlor or simply the notification popped out on the device screen. It does not rely on how the steps are executed, they demonstrate the continuous flow of interactions that would follow in the task of getting the juice delivered.

These sets of interaction in a microservices architecture enable design of the process or message flow, and hence it has helped the developers and architects, who use microservices to get clarity to their interface definitions. As for the protocols, once the interactions and interfaces are set, with the continual advancement of HTTP – like HTTP2 – and the increasing efficiency of the asynchronous protocol, ecosystem gaps are getting reduced on all aspects. It will become quite common that the correct approach is not to select one or the other protocol but identifying the one that is best for the given interaction.