In this article, we will learn about Reactive Microservices. We’ll also discuss the transition of an application from Monoliths to Service Oriented Architecture to Reactive Microservices. When it comes to Microservices, there are various questions that we need to answer. How big is a Microservice? What are the differences between Monoliths and Microservices? What makes a good Microservice System?
We will try to answer and get an understanding of these questions in detail in this article. In this article, we’ll learn various terminologies related to Reactive Microservices. We’ll also look through their characteristics and their pros and cons. We assure you that by the end of this article you’ll have answers to most of your questions related to the Reactive Microservices.
Also Read: Reactive Architecture: A Modern Architectural Style
When Reactive Meets Microservices
Before we move directly to the microservices. Let’s first try to get an understanding of Software Spectrum. So as you can see in this arrow diagram below, it represents a Software Spectrum. Software spectrum has monoliths at one end and microservices at the other. Any application that we design generally lies somewhere on this Software Spectrum. It’s the transition on this spectrum that is of utmost importance.
So as we have already told you that most of the applications lie somewhere on the Software Spectrum. That means they have certain features of Monoliths and certain features of Microservices. Now, this is something we need to understand that to what extent we require the nature of Monoliths, or to what extent we require the nature of Microservices, for our application.
We can now start by looking at Monoliths and what were the problems in them that led us to the design of Reactive Microservices.
Monoliths
To start learning about microservices it’s important to compare them to monolithic applications. A monolithic application is one that is deployed as a single unit. Monoliths share a single database.
They communicate with synchronous method calls where you have a request-response scenario, in this case, you send a message and expect a response immediately.
Characteristics of Monoliths
- Deployed as a single unit
- Single shared database
- Communicate with synchronous method calls
- Deep coupling between libraries and components
- Long cycle times (weeks to months)
- Teams have to carefully synchronize features and releases
Pros of Monoliths
- Easy cross-module refactoring
- Easier to maintain consistency
- Single deployment process
- The single thing to monitor
- Simple Scalability model
Cons of Monoliths
- Limited by the maximum size of a single physical machine
- Deep coupling results in inflexibility which lead to slow development
- Serious failures in one component bring down the whole application
- Scale only as far as the database allows because they rely on relational database
- All components have to be scaled as a group even if only some of them require scalability
- Have to deploy an entire application on each update
Service-Oriented Architecture (SOA)
Service-Oriented Architecture (SOA) is an architectural style that structures an application as a collection of smaller independent services. These services don’t share a database. Each of these services has its own database, logic, and domain.
These services can communicate with each other through the means of synchronous or asynchronous messaging. Since these services are not exposed to each other, they communicate through some well and clearly defined APIs. SOA gives us the flexibility to deploy our application. The application can be deployed as independent units that closely resembles Microservices or as a Monolith application according to our requirements.
Characteristics of SOA
- We can introduce additional isolation using Service Oriented Architecture.
- Anybody who wants information about any service has to go through the services API.
- There’s now no coupling between the different parts of the application and the database.
- Services can be physically separated, independently deployed, and scaled
Pros of SOA
- Isolation and lose coupling between services
- Any change to one service does not affect others
- Failure in one service does not cause cascading failures to others
- Services are accessible through external APIs only, thus free to evolve underlying code
- Support multiple platforms and languages
- Shorter release cycles
Cons of SOA
- Greater load and increased response time.
- Complex service management.
- Requires large upfront investment.
- Each service shares ESB leading to a single point of failure.
Microservices
The difference between Microservices and SOA is that SOA doesn’t dictate any requirements around deployment. You can deploy SOA as a monolith or you can deploy each of its services independently. If you deploy them independently that’s when you start to build microservices.
In Microservices, services have to be deployed independently unlike SOA. Apart from this, Microservices follow all rules provided by SOA. This means that you can put the services to many different machines. You can have any number of copies of individual services depending on your requirements.
Characteristics of Microservices
- The subset of Service Oriented Architecture(SOA)
- Multiple independent databases.
- Communication can be synchronous or asynchronous
- Loose coupling between components
- Rapid deployments
Pros of Microservices
- Takes up all benefits of SOA without its disadvantages.
- Each service is independently deployed on different machines, thus each service can also be scaled independently.
- Increased availability
- Serious failures are isolated to a single service.
- We can create any number of copies for individual services based on requirements.
Cons of Microservices
- May require complex deployment systems and complex monitoring approaches
- Cross service refactoring becomes harder
- Requires supporting older API versions.
- Organizational change to microservices is a challenging task
Reactive Microservices
The Reactive microservices are just an extension to the Microservices architecture with few added restrictions. The transition of an application from Microservice architecture to Reactive Microservice architecture is done by creating isolation between the Microservices. This isolation can be done by using various isolation techniques which we will cover in another article.
Also, one major difference between the Microservices and Reactive Microservices is that the Reactive Microservices should definitely follow the Reactive Principles, which means that, each microservice should be responsive, resilient, elastic i.e. scalable and message-driven, on its own. The core of Reactive Microservices is finding ways to create more isolation between Microservices.
Conclusion
In the end, Let’s just look into some advantages of Reactive Microservices and why we would put in so much effort to achieve them. In the Reactive Microservices system, each microservice has the isolation property and therefore does not impact other microservices, even when failing. Along with that, The Microservices are autonomous, event-driven, have a single responsibility, can be moved at runtime but can be reached regardless of its location, and owns their data exclusively. In the modern-day scenario, these properties are of great worth and this is one of the main reasons why the industry is moving towards Reactive Microservices.
From a business point of view, Reactive Microservices deliver several benefits when it comes to development and cost management. Companies find that incorporating reactive principles in their microservices results in highly responsive and effective systems that deploy faster, cut costs and delight end users.
