Microservice Architecture is used for building large enterprise applications with multiple small functionality called services. The services are loosely coupled enabling them to be developed, deployed and tested independently.
Services can use REST with JSON for communicating with other services. The services can be deployed in a single machine or across multiple machines
Useful facts about Microservice
- Services run independently on their dedicated process.
- Loosely Coupled : Services can be updated independently of other services
- Services communicate either through HTTP/REST synchronously or AMQP (Advanced Message Queuing Protocol) asynchronously
- Uses its own data store in order to be decoupled from other services
- Improved fault isolation – If one service has a problem then that service can be isolated and analyzed without affecting the working of other services
- Scaling of services based on demand is possible rather than scaling all services
- Easy discard of services. If a services is not popular then that service can be discarded easily
- Deployment of services is easier
- Microservice contains only business logic code.
Best Practices for designing a Microservice
- Separate DataStore – Design each Microservice with a dedicated data store. Need MDM (Master Data Management) tool to keep all data stores in sync
- Maintain all Microservice code at same level of complexity. For any new enhancements to the Microservices , it is better to create a new Microservice than enhancing the existing already stable service
- Separate build for every Microservice . This enables an efficient way of defining the required dependencies
- Deploy the Microservices in containers like Dockers
- Treat the servers stateless – Under performing servers should be replaced anytime
Constraints of a Microservice design
For a service to be a Microservice it needs to full-fill certain requirements
- Should be scalable. Based on the performance requirement the services should be able to be fine tuned
- Failure resistant – Failure of one service should not affect other service or the application .
- Should offer a uniform interface and should support aggregation,linking, caching, proxies and gateways.
- Microservice should follow SRP (Single Responsibility Principal) OOO principal
- Every Micorservice should offer a complete functionlaity
- Operations overhead
- Require DEV-OPS skills
- Duplicated effort to maintain loose coupling
- Distributed system is complicated
- As the services grow maintainability becomes a huge concern