Microservices and the Saga Pattern, Part 2
Microservices and the Saga Pattern, Part 2
We continue our investigation of microservices by looking at the prevalent architectural patterns in software development and how microservices stack up.
Join the DZone community and get the full member experience.Join For Free
Record growth in microservices is disrupting the operational landscape. Read the Global Microservices Trends report to learn more.
Welcome back! If you missed Part 1, you can check it out here.
I hope that by now you are pretty much clear about what a microservice is and have started analyzing the strengths and weaknesses of it. I tried to keep it simple by giving just an overview of what a microservice should look like, but there’s a lot more to it that I won’t be covering in this series. Though I would like to mention a key difference between microservices and SOA (Service Oriented Architecture). Yes, the two are not the same and that is because SOA does not talk about the service deployment and it is the reason that when we build a system using SOA we end up building it in a monolithic style, where all the services are deployed altogether as one application. On the other hand, microservices are a subset of SOA, but they require that each of the services is independently deployed, meaning that they can be put on many different machines and any number of copies of the individual services could be deployed.
So let’s look at the advantages of using microservices:
- Rapid Deployments: Since each of the microservices is independent of the deployment of other services, this leads to rapid deployments within an application.
- Database: We can have multiple independent databases.
- Loose Coupling between the components of the application.
- Communication between the components could be in the form of synchronous messaging or asynchronous messaging (reactive microservices), however, the asynchronous mode is preferable.
- Scaling Microservice: Each of the microservices is scaled independently.
- Failure Isolation: Failures are isolated to the originating source and they do not cascade to the other services (which would cause the entire application to fail rather than just the source of the failure). The service’s functionality is the only thing that gets affected, thus leaving the rest of the application's functionalities working properly.
Just like with monoliths, there are have advantages and disadvantages to microservices. A few disadvantages to microservices are:
- Complex Deployments: We may have many microservices in an application and those services could be written in different languages that may lead to complex deployment systems.
- Complex Monitoring: A large number of microservices are deployed, which means we need a way to monitor multiple services to see if any of them are having a problem. This is not the case with a monolith, where we just monitor the one application as a whole.
- Support Older Versions: We need to provide continuous support for an older version of the API so that our customers who are still using that older API version can continue to perform their daily operations without any hassle. So the general convention is that we keep at least two versions (current and he current’s closest predecessor) deployed for the same service until all the customers have migrated to the newer version (there are certain issues to that approach as well but that’s a story for next time).
So moving on to our next question, what does it mean to be reactive?
We say that a system is reactive if it follows the principles of reactive architecture. This means an application must be:
- Responsive - The system should be able to respond back to the user in a specified time (t) under the circumstances (some negligible deviation is accepted though) whether there’s heavy traffic or nominal traffic. If a system’s response time degrades with the increasing load then it is not considered responsive. A reactive system consistently responds in a timely fashion.
- Resilient - Being resilient means that the system, even if it is suffering from some internal problem (failures) should be able to stay responsive and should continue to provide the user a response in the same time (t) as it would have provided if there were no failures internally.
- Elastic - A system is said to be elastic if it can scale up or scale down as per the requirements. This results in better resource utilization. Elasticity implies that we cannot only scale up when needed but then when the load decreases we can scale back down in order to conserve resources. The Reactive Manifesto states that a system needs to be both resilient and elastic in order to achieve responsiveness. A reactive system remains responsive, despite changes to system load.
- Message-Driven - Reactive systems rely on asynchronous messaging to establish a boundary between components that ensure loose coupling, isolation, and location transparency. Non-blocking communication allows recipients to only consume resources while active, leading to less system overhead.
We can conclude that the primary goal of reactive architecture is to provide an experience that is responsive under all conditions. More information is available here: The Reactive Manifesto.
That's all for Part 2! Tune in Monday when we'll discuss Saga Patterns.
This article was first published on the Knoldus blog.
Published at DZone with permission of Prashant Sharma , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.