Microservice: Do we need it in every Application?

Microservice or microservice architecture involves building an application using a collection of loosely coupled services which are highly maintainable and testable and can be independently deployed. It helps in the delivery/deployment of large, complex applications.

There are a lot of myths surrounding the microservices architecture. Let us bust two of the more common ones together!

Myth-1. Microservice involves small and easy to understand code and the codebase can be managed easily. Although it is not entirely incorrect, that is not what microservices is all about. We have been using OOP and libraries which have been doing the same thing for long.

Myth-2. If one microservice fails, it does not impact other services. This may not always be true. Because even with microservice architecture, there may be dependencies among different services. Also, it is very hard to write code that gracefully recovers failing issues. But what differentiates microservices is that there are multiple instances of the same feature running. Contrast this with monolithic applications where the whole application either runs or fails to run. You cannot do it feature-wise.

Now let us look at some of the important benefits of Microservice Architecture.

1. Scale independently: In this architecture, each piece/service/node can scale independently.
2. Multiple technology stacks: Each service can run on a different technology stack. For example, one service can be in Java and others can be on Node.js.
3. Independent deployment: Each service can be deployed independently. But a word of caution. Do not forget integration testing with other services.
4. Use of multiple library versions: In microservices, different services can use different versions of libraries. Fixing dependency conflicts have become much easier as compared to monolithic codes.

Microservice Networking

In case of the monolith, the call to any API is reliable, high performing, highly secure, and easy to debug, and fast as there are no network calls. Let’s compare this to how a call is made in microservice:

Performance: not as good, with increased network congestion

Unpredictable time: managing timeout is a challenge.

Unreliable: requires retries and some circuit breaker pattern implementation. The server code must be idempotent*

Security: as it is a web API, it can be called from anywhere, thus requiring authentication, authorization, encryption

Debugging: it is not easy in microservice because if any issue arises, you need to see if it is due to network or software or due to any other reason. Also since logs are distributed across various nodes, we need to aggregate all logs to understand what happened. Having logs from one node may not always give you the required information needed to debug.

*(if a server is processing any client request and there is a timeout at the client-side, the client will send the same request again to the server. Developers need to handle this at the server-side so that the same request is not processed repeatedly)

Microservice Discovery

Since we have a cluster of nodes of services to connect to any service, we need information such as IP address and Port. Also, since services can be created dynamically, there won’t be any fixed IP or port. A service Registry (naming service) will have key-value to identify a service based on the service name. This registry would have information on all the services with key as service name and value like IP and port.

Fig 1 — Microservice Discovery

Microservice Load Balancing

Load Balancing (LB) is another important feature in a microservice architecture. To set up load balancing with, let us say, probes of 15 sec, LB needs to keep checking the status of each node at an interval of 15 sec. If any node is down or any issue is encountered by the probe, it will return a response code! = 200 and the LB will not send traffic to that particular node.

Fig 2— Load balancing