Broadly speaking, there are two types of microservices:
Stateless microservices
Stateful microservices
Stateless services are good candidates as the building blocks of a distributed system. As the name suggests, stateless microservices do not maintain session state between requests, for example, if any of the service instance is being removed, it does not affect the overall processing logic for the service. Distributed systems do prefer stateless microservices.
The ORDER diagram
If we look at the earlier diagram, a customer makes a request for a product through the ORDER service, and internally, the ORDER service checks for the product status through the INVENTORY service. Stateless means each request happens independently of the previous or future requests. One call to get product details would return the same result regardless of the previous context or requests. If one call to the ORDER service fails, then it should not halt whole business processing. There should be another instances of microservices running to take up the task.
Stateful microservices store session information in the code. When two or more microservices communicate, they maintain a service request state.
In the real world, stateless services are a good choice, but there are multiple use cases where you need to keep state information. If we think of a simple example, then transactions that require multiple database roundtrips require state to be stored.
To read more about stateful microservices, you can refer to the link: https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview.
We have seen how microservices can be useful in creating distributed systems and can be optimized as per business requirement. As we progress through microservices concepts, it is also essential to discuss some of the following microservice challenges so that you can determine if it's the right design for your solution:
Application logic: Unlike monolithic where you have all logic embedded inside the same solution package, application logic in microservices design pattern is distributed, and the whole logic behind your solution is distributed among multiple microservices.
Various microservices calls with correct data and correct sequence of call makes your Application logic. This makes it harder for operational people to effectively manage and monitor the application.
Testing limitation: While using microservices pattern, we are limited to testing scenarios. We cannot easily find all the possible interactions among microservices deployed, and it makes harder for us to come up with the exact test cases and results.
This makes change complex as we cannot predict whether a small change might break functionality of other dependent microservices.
Multiple technology: The microservices architecture supports the use of multiple technology in developing stateful and stateless microservices. This concept finds some problem with real-life applications where you use third-party assemblies and libraries. It makes harder to organize your solution because of high dependency on third-party software.
Monitoring: With microservices, organizations may find difficulty in monitoring the distributed environment as a whole. Technologies such as Docker and container concepts do ease the process of monitoring. They add one more layer of abstraction to your microservices.
Before we go into difference and similarities of SOA and microservices, it is better to move a step back and explain what is Service Oriented Architecture (SOA). What we understand from SOA: It is a design pattern or approach to build Application Architecture based on services. Each service has a specific set of functionality such as taking customer Order and Validating Order request.
With the definition of SOA, we can really see similarity between SOA and microservices. If we try to define microservices in terms of SOA, then we can say that "microservices is a fine grained SOA Architecture style with a set of common features like decentralization, isolation, automation, overs able etc. We can also say that Microservices is subset of SOA".
The diagram showing that Microservices is a subset of SOA
We have discussed microservices concepts in the earlier sections, and it is apparent that there is a lot of similarity with SOA design patterns. The preceding diagram shows how microservices and SOA are interrelated. We can say microservices is a subset of SOA based on the concept defined for SOA and microservices.
SOA is a wider concept; thus, the scope for problems with this style is larger. In SOA, defining a correct service boundary is always a problem; it is simple to how big or how small the service should be. Some useful concepts and technique of SOA, such as shared library and shared database, are totally been discarded from microservices.
