What and Why Microservice?
Microservice is an Architectural Pattern designed for application to make it:
- Highly maintainable and testable
- Loosely coupled
- Independently deployable
- Organized around business capabilities
- Owned by a small team
Pro & Cons
| Pro | Cons |
| Loose coupling: minimise the dependencies between the components.This makes specific service changes and switching or replacing service implementations very easy. | Lack of database safeties: extra effort is required to keep data consistency and maintain transactions, as each microservices have own database. |
| Technology Independent: we can use different languages for different microservices as communication mostly happen through REST APIs. | Performance : microservices architecture requires REST API or Message Bus for inter communication, i.e slow calls between services compared to local calls. |
| Independent life cycle: each microservices deployment and development is independent of other microservices | Monitor & Debugging: each microservices has it’s own logs, due to this difficult to debug and monitor. Third party tool needs to aggregate logs. |
| Horizontal Scaling: microservices are small application and easy to define scale policy, this helps to improve performance. | Cost: microservices consumes more resources compare to single application due to this deployment cost get increased. |
| Communicates: microservices communicates with other microservices by a well-defined interfaces. e.g Rest API JSON Response. | Redundancy: microservices are independent application due to this code possibility of duplication. This can reduced if underline technology supports plugin or library. |
| Testing: microservices architecture requires extra testing efforts to test each service boundary. |
Are Microservices right for your application or just want to use it because of Buzz word and it’s popularity?
- Module Change/Integration Frequency : Does you application modules has different interaction frequency? In any application some modules hardly changed and some changed quite frequently. Separate frequently changed module in to services.
- Independent Life Cycles :Some module may have different deployment life cycles. e.g An application has security, Authentication and Authorisation module that may have own code repository and deployment life cycles. Separate Independent Life Cycles Modules.
- Module Scalability :Some modules may have different load or throughput characteristics, they may have different scaling requirements. Separate such modules.
- External Dependency (Optional): Application depending on external services. e.g Application depends on payment processing service, that change frequently, then it good to keep it separate. Also if you can change the external dependency without affecting application.
- Team Collaboration : Multiple teams are working on application or Multiple stack holders for the application module, in this case its better to separate such module to separate Microservice (NOTE: if server does not fall in first three categories)
Example
Think, Design, Develop and Deliver 