The industrial trend to adopt microservices for development has been there now for some time. In recent times, this trend has gone further ahead to use reactive microservices architecture for the system design for one of the many advantages they offer. Reactive microservices system have services which are isolated from one another using various isolation techniques for reactive microservices.
In this article, we’ll look at how we can achieve isolation property in reactive microservices system. Well, there are not some but many techniques used by developers for isolating their services. We’ll look through some of the most common and widely accepted isolation techniques for reactive microservices in this article.
In this article, we’ll be covering various isolation techniques for reactive microservices. We need these isolation techniques to make our microservices more responsive, resilient, robust, and elastic.
In this technique, we try to create failure zones within our application. So that when a failure occurs, we can isolate it to that zone and it’s not going to propagate to other services. If we have a microservice that can act as a failure zone, then that means that a microservice will fail but other services can continue to operate. The idea here is that the overall system can remain operational even in the face of reasonably significant failures, though it might operate in a degraded state.
This technique takes inspiration from partitioned parts of a ship’s hull. A bulkhead is a partition built between different cargo sections in the ship. In case of breach of any of the sections of the ship, the bulkheads prevent the water from flowing into the other sections. This allows the ship to continue to operate after what otherwise might have been a catastrophic failure.
2. Circuit Breaker
A circuit breaker is a way to avoid overloading a service. What they do is quarantine a failing service so that it can fail fast and allow it to recover fast. So we have three states for the operation of Circuit breakers:-
Closed State: In normal operations, our circuit breaker operates in a closed state. That’s the green circle in the diagram. In the closed state, any request that gets sent just goes through to the external circuit and everything works as normal.
Open State: In the open state, all calls are immediately failed without contacting the external service. It means that the external service now has a chance to recover. We’re not going to continue to put more and more load on it. The red circle in the above diagram represents this state.
Half Open State: In the period of time, when the circuit breaker attempts to reset itself. At that point, it goes into the half-open state.
3. Message Driven Architecture
In message-driven architecture, microservices use asynchronous and non-blocking messages. Thus, they are not dependent on the response from each other. Asynchronous messaging allows us to free up things like memory resources. It allows us to free up CPU resources. We’re not occupying threads. We can use all these things for other tasks.
As a result, we become more isolated in both time and failure. Our services are less likely to fail. They become less brittle and they’re not dependent on things to happen immediately. It results in systems that are going to be more robust. So if a request to a microservice fails, the failures won’t propagate.
4. Autonomous Microservice
Microservices can only guarantee their own behavior. They communicate through their API. They can’t guarantee what other microservices are going to do. Autonomy provides both stronger scalability and availability. Also, fully autonomous microservice can be scaled indefinitely. They have no dependencies so nothing is preventing you from scaling forever. A fully autonomous system is a pretty rare possibly non-existent thing but the closer we can get to fully autonomous the better situation we’re going to put ourselves in. A fully autonomous service can continue to operate, even if it is the only part of the system still running.
We can achieve Autonomy using eventual consistency and by communicating only through asynchronous messaging. Moreover, avoiding any kind of direct synchronous dependencies on external services helps in creating autonomous services. At the end of the day, it’s all about finding ways to isolate your microservices. The more isolation you can put in, the more autonomous your microservices are going to be.
5. API Gateway Service
Well, one of the disadvantages of reactive microservices is that they can create complexity, particularly in your client application. This increase in complexity is problematic. If we want to deprecate a microservice or move it or add an additional microservice we can’t do that until we ensure that all the clients are up to date.
We use the API Gateway Service to manage these complexities. This API Gateway Service is put between our individual microservices and our client. Our client now makes a request to the gateway service and then the gateway service knows about all the individual services that it needs to talk to in order to fulfill that request. So it sends the requests to individual microservices and aggregates the response.
Then if a failure occurs on one of the individual microservices, the gateway service is responsible for figuring out how to deal with that failure. Thus we’re creating an additional layer of isolation between our client and our individual reactive microservices.
The industry is gradually moving towards reactive systems from traditional monoliths. Although It provides several benefits, it also poses some challenges to developers. One of those challenges is to isolate the microservices, to make them more failure-prone and scalable, along with other advantages. Different isolation techniques provide isolation in one or more principles of isolation. It is important to know which technique provides isolation in which principle to choose the right technique for your need. We hope we were able to give you enough information about the techniques discussed in this article, to help you achieve your target.