Microservices has been a buzzword in software engineering recently. Everyone wants to build their application around Microservices architecture. Before you jump onto the bandwagon, lets do a critical review of Microservices. We will look at the cases where it is appropriate along with advantages and disadvantages.
Before we proceed let us look at how to define a microservice. Wikipedia says:
In computing, microservices is a software architecture style, in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task.
- Addresses a small problem domain.
- Is built and deployed independently.
- Runs in its own processes.
- Segregates data and config for its own use.
- Integrates via well known interfaces.
A collection of such microservices forms a usable application.
When to use Microservices?
- The system is too complex or too big and it becomes difficult to manage.
- The system is expected to handle high traffic & load and needs to be highly scalable.
Drawbacks of Microservices
- Adds complexity to development due to its distributed nature.
- Adds overhead in terms of costs and operational complexity (build-test-deploy-run).
- Time to market may be hit adversely due to the distributed nature of the application.
- Monitoring the application in production deployment becomes a complex job, with multiple services.
- Service interface versioning needs to be managed for the multiple services.
- The operational challenges of Microservices architecture mean you need high quality DevOps and release automation skills as part of your development team.
- The asynchronous communication and distributed nature of the microservices based system poses challenges for testing the system as a whole.
- Operational expenditure could be significantly higher depending on the complexity of the system.
Benefits of Microservices
- Systems are inherently scalable as the services built this way are loosely coupled. The scalability is improved further if the communication between the services is asynchronous using a Enterprise Service Bus (ESB).
- It improves the team autonomy as smaller team have complete control over the microservice. These smaller team can deliver at a higher speed of delivery as they are focused on the specific service.
- It highly increases the overall availability of the system when combined with Fault Tolerant Architecture.
- It allows each service to be built using the most appropriate tool and language for the job.
- Multiple teams can deliver relatively independently of each other under this model.
- The approach eliminates long-term commitment to a single technology stack.
- The development efforts are more scalable as one can develop, deploy and scale each service independently.
- The product is more agile as defined interfaces can be use to completely swap out components if required.
The recommended approach that has worked with many teams is to start with a monolithic design with a clear mandate to break it down later into services and as boundaries between services become clear. This phased approach from monolithic to microservices has a higher success rate as compared to starting out with microservices from scratch. Start with a microservices approach right from the start only if you have extreme clarity about the service boundaries.
On the flip side, be aware and educate your team of your long term strategy so you do not get stuck with monolithic glop beyond v1.0.