In this article, we’ll learn about the principles of isolation. When building microservices, one of the primary goals is to achieve a higher degree of isolation between components within our application. As a result of isolation, Microservices built have loose coupling and increased scalability.
Reactive Microservices have isolation in State, Space, Time, and Failure. All these principles of isolation have their importance and advantages. We’ll see in brief detail what each of these principles of isolation is in this section. You can also check isolation techniques for Reactive Microservices.
Principles of Isolation in Reactive Microservices
Let’s have a look at the principles of isolation in Reactive Microservices. They specify the basis on which we can isolate our microservices. By following these principles, microservices are independently deployed and executed within a separate process.
1. Isolation of State
Firstly, we have the isolation of the state. This principle allows the reactive microservice to evolve internally without affecting the outside because it only communicates through the public-facing API. We do not have any backdoor access through the database and hence the API is the only mode of communication.
As long as we maintain that public-facing API, nobody needs to know what happens under the covers. Nobody needs to know that we have changed databases, and restructured the database, nobody needs to know that we rewrote the domain code. Therefore, All of that can evolve independently. That’s the main idea behind the isolation of the State.
2. Isolation in Space
Next, we have Isolation in space. Reactive microservices are independently deployed. They do not care about the location of other microservices. That is to say, it does not care whether it is deployed to the same piece of hardware or maybe a different piece of hardware.
Likewise, It does not care whether it is deployed in the same data center or maybe a totally different data center. It has a single method of communication that works no matter where the other microservices are deployed.
As a result of this, we can scale up or down the microservices to meet the requirements. We can spin up any number of copies of the Customer service if necessary across many different pieces of hardware without any issues.
If possible we may even have them deployed on different data centres. Therefore, even if we lose an entire data center the application continues to operate normally.
3. Isolation in Time
Next, we have isolation in time. In reactive microservices, requests are asynchronous and non-blocking. This allows us to use our resources more efficiently. Rather than having a situation where we send a request, and then block a thread while we wait for a response. What we’re doing is we send a request and then we walk away.
That allows for more efficient use of resources because we don’t have to occupy that thread and threads aren’t free. Also, it’s not just the threads, we can free up things like memory, we can free up CPU, all of these things.
Between microservices, we expect eventual consistency. Within a microservice, we can perhaps have strong consistency but between microservices, we expect eventual consistency. This provides increased scalability.
4. Isolation of Failure
At last, we have isolation of failure. The main idea of this principle is to isolate the failure, which in turn prevents cascading failures. Therefore, It allows the system to remain operational despite failure.
The more we follow this principle, the more robust our system is going to be. In an ideal case, if we can get to the point where any one of our services can operate completely independently of all the others, then that leaves us in a really good state.
What is the Need for Isolating Microservices?
- By increasing isolation within the application, we can achieve flexibility and power.
- Isolation restricts access to the data of the service strictly to that service’s API.
- Limiting access to the API of service allows the underlying persistence model to have complete abstraction from the application’s other services.
- Isolating applications in space helps us to manage resource utilization by allowing us to redistribute an application’s components dynamically.
- Isolating the application in time using asynchronous service calls eradicates the need for resources to wait for long-running requests.
- The distribution of load across the isolated application is way better than the load distribution followed by service-oriented architecture.
- Isolating the application components from failure prevents cascading failures.
- Isolation avoids the crashing of the entire application as there is no single failing component.
Conclusion
One of the biggest issues we can face when dealing with microservices is to ensure each microservice operates in complete isolation from its microservice siblings. There are plenty of great tools and cloud services out there nowadays that can help us follow these principles of isolation in Reactive Microservices.
However, it is up to you to ensure you avail yourself of them, and you build your platform in such a way that you avoid tight coupling and increase scalability as much as you can.
