Any architecture demonstrating the following six principles or characteristics could be placed in the microservice architecture zone:
- The system should consist of two or more running units or components. These components should expose their functionality as services. Each component should serve a business purpose, and the components should be loosely coupled. Components should communicate with each other through predefined protocols, such as messaging queues, HTTP request/response models, and so on.
- Systems should be language agnostic. One component can be developed in Java, and another can be developed in .NET. The decision of choosing a technology platform for a particular service should not affect the application architecture.
- Systems should have a decentralized database. Ideally, each component or microservice should have its own database, with whom only that service is interacting. No other component or service can fetch or modify the data in that database.
- Each component in the system should be cohesive, independent, and self-deployable. It should not be dependent on any other component or resource to work or to deploy. It should have Continuous Integration/Continuous Deployment (CI/CD) in place to ship faster.
- The system should have automated testing in place. Speed is the one of the most desirable features of microservice architecture. In the cycle of build, test, and ship, if automated testing is not in place, then it cannot meet the goal.
- Any component/service's failure should be in isolation. Failure of one service should not make the whole application go down. If it fails, it should not affect other components/services. Some kind of failure roll back mechanism should be in place. That means if one service fails, it should be easy to roll it back to an older working version.
This simple and small example given below may give a better understanding and more insight into these principles.
An application is required, that generates coupons for shopping online on the basis of privileges given to a registered user. If a user is from the platinum category, they will have a 20 percent discount coupon, gold users 15 percent, silver 10 percent, and guests 5 percent.
In this architecture, there is scope for two microservices. The first is for authentication that gets users logged in based on the credentials provided and sends the privilege level back to the consumer as a response. The second is based on privilege level. The service should return the percentage of discount that may be applied on the cart (another service) built by the consumer.
In the following diagram, there are two components having two different Databases. Assuming both components have exposed their services as REST interfaces, consumers can hit Authentication Service MS1 with credentials and get the user object, including privilege level, and then, it can hit the second microservice with privilege level and get the discount coupon percentage:
Each service servers a business purpose (rule 1). Both services can be on different platforms; it will not affect the existence of the other service (rule 2). Both services have different databases with which only that particular service is communicating (rule 3). Services are independent of each other which means not sharing any database among themselves and self-deployable ( assuming CI/CD in place rule 4).
If we assume here Authentication Service MS1 dies in some rare circumstances because of a runtime exception or memory leakage issue, the consumer will get an HTTP response of 404. 404 (Not Found) is treated as user not found in the database, which will lead the consumer to treat this user as a guest, and it will still keep asking for a discount coupon for the guest. The system/website will be up and running. Failure of Authentication Service MS1 will not hamper any other running service. (rule 6 isolation failure.)
If the same problem occurred in a monolithic application (memory leak), it would require rebooting the whole application, including all components, and it would cause a downtime.
The success of microservice architecture is based on how efficiently one analyze the problem domain and broke down the application into smaller independent components. The better the assorting of problems, the better the architecture will evolve. The typical architecture of microservices is as shown in the following diagram:
Normally, each team is responsible for one microservice. The size of a team can vary from one member to many with the size and complexity of microservices. Each microservice has its own release plan. Deployment of one microservice doesn't affect the deployment of an other microservice. If, at a particular time, five microservices are in testing and quality analysis (QA) and only two pass the QA phase, then only those two can ship to production, and they should not be affected by or dependent on the release of the rest of the services.