Microservice Architecture and Safety Considerations — Part 1

As we know Microservice applications are deployed in separate services in a cloud environment. Each service API is exposed in a different API path under the same domain/separate domain. In this article, the author tries to discuss the Microservices Architecture application's security-related issues and precautions, in this article mostly will be discussing interservice communication between the microservices.

In a cloud-native environment, each service is deployed in a loosely coupled way. Usually, each service has separate databases. But when compared with Monolithic applications we can call the functions and do the appropriate necessary developments but in microservice applications, a distributed system is running on several different virtual machines, and each service is a component or process of an enterprise application.

If we want interservice communications like features. Most of them prefer HTTP requests. In this situation when one service was called on the client side and another service that is going to accept the request is called on the server side. Usually, if the client-side initiated the request it needs to wait until getting a response. So it can problem because of the API failure and also there can be timeout issues. In security-wise, there can be a possibility to happen Man in the middle attacks, during the API calls between the microservices.

To avoid the above-mentioned security issues we can go with GRPClike Protocol service. It is Google Remote Procedure Calls (gRPC) is an open-source Remote Procedure Call (RPC) system used to provide communication between microservices. It also provides various features such as authentication, blocking or nonblocking bindings, bidirectional streaming and flow control, and cancellation and timeouts. When compared with HTTP requests GRPC is more faster. Usually, HTTP and GRPC interservice communications are called synchronous communication.

Asynchronous one-to-one communication, messaging, and event-driven communication are critical when propagating changes across multiple microservices and their related domain models. In this communication approach, each request of a service client is processed by multiple service instances. There are the following kinds of one-to-many interactions

• Publish/subscribe: In this approach, a Client publishes a notification message to the message broker and this notification message is consumed by zero or more interesting services.
• Publish/async responses: In this approach, a Client publishes a request message and then waits for a certain amount of time for responses from interested services.

So based on the above article we can come a decision based on our business purpose technical knowledge we have to choose proper methodology during the development of microservice interservice communication

The next article will discuss more about authentication in microservice applications.