Organizations are increasingly drawn towards building their large business applications in an architectural style known as microservices architecture which structures an application as a group of loosely coupled, independently testable and deployable services organized around specific business functions. Such an architecture provides many benefits relative to a conventional, monolithic application—improved scaling, ease of maintenance, isolation of business logic and data, and rapid and frequent deployment for specific business functions.

The multiple, independent services which comprise a microservices application need to collaborate with each other using some form of inter-process communication (IPC) mechanisms, of which there is a wide variety to choose from. Services can use synchronous request/response-based technologies like REST or gRPC, or asynchronous, message-based ones like AMQP. Services can use human-readable text-based message formats like JSON, or XML, or more efficient binary formats like Protocol Buffers. They can also use high-level network protocols like HTTP or low-level but more efficient TCP.

The choice of the right IPC technology depends on several parameters: need for scalability and performance, availability of the right expertise, and its fit within the enterprise technology stack.

Synchronous interaction means that the client waits for the response from the service. In the simplest case, the client blocks until the service returns with a response. However, it is also possible to build asynchronous interactions using these technologies. For example, when a request initiates a long running process in a service, the client, instead of waiting for it to complete, can implement a pattern like polling in a separate thread to periodically check the service for completion. Alternatively, the service can push a notification to the client on completion. Services using gRPC for example, can push messages to a client in real time without polling.

Technologies like REST, SOAP, gRPC, and WebSocket are examples of the most widely used synchronous communication technologies.

REST

REST (Representational State Transfer) is a set of architectural principles which enables integration between systems & applications. Business objects, known as resources, are accessed or updated through a web-like endpoints, known as URIs (Uniform Resource Identifiers.) REST relies on HTTP, as its transport protocol, and utilizes the standard HTTP request methods, such as GET, POST, PUT, DELETE etc. to implement a service. REST services can use a variety of text-based message formats like JSON, XML, YAML, etc. REST based APIs are lightweight, scalable, widely supported, have great support for browsers and other tools, and easy to implement. It however suffers from limitations around lack of discoverability, message standards, and type-safety.

SOAP

SOAP (Simple Object Access Protocol) is a service communication protocol which enables systems to invoke services remotely, using XML as the message format. Unlike REST, which enables access to resources or business entities, SOAP exposes components of application logic as services rather than data.

SOAP based services have been around for many years and most modern technology platforms like Java and .Net and corresponding IDEs have extensive support for building and integrating with SOAP services. SOAP web services support service discoverability and strong type checking. Among the disadvantages of SOAP are that the standards (WS-*) associated with SOAP are very complicated, and SOAP services are heavyweight and computationally expensive. The SOAP standard is now considered a legacy technology and not the preferred option for new application development.

gRPC

gRPC is a modern, RPC communication framework, which uses highly efficient HTTP/2 as its transport, and protocol buffer (or protobuf) as its binary messaging format. RPC, or Remote Procedure Call, is a method to remotely execute a procedure on a separate service. Although less established than REST or SOAP based services, gRPC is increasingly gaining popularity for implementing inter-services communication due to its scalability under high load. gRPC supports several connection options—single request/response, client and server streaming, and bidirectional streaming. gRPC can also push messages in real time without polling. Being relatively new, however, gRPC lacks extensive tooling and browser support.

WebSocket

WebSocket is a communications protocol which allows services to send and receive information bidirectionally, in real-time, both synchronously and asynchronously. Also due to its support for binary messaging, it has less overhead than REST while transferring large amount of data. For applications requiring constant real-time communication like chat, streaming media, multiplayer games, WebSocket is the preferred approach. However, it may be an overkill for less demanding applications, and it also lacks extensive tooling support.

Support for WebSocket is built into the Microsoft stack through the SignalR library.

In an asynchronous interaction model, the requester need not wait for the response. Services communicate by exchanging messages using a message broker, which acts as an intermediary between the services. Using a messaging framework, services can implement both synchronous and asynchronous style of interactions. Among the popular messaging technologies are RabbitMQ and Apache Kafka.

Messaging technologies will be covered in a subsequent post.

In this post we provided a brief overview of various microservices communication frameworks. Subsequent posts will explore some of these communication mechanisms in depth and provide recommendations for modern microservices development.

Microservices Communication Frameworks—Part 1 bye Ranjan Bhattacharya