Why Monolithic to Microservices?
As monolithic systems become too large to deal with, many enterprises are drawn to breaking them down into the microservices architectural style. It is a worthwhile journey, but not an easy one.
Why Monolithic?
Monolithic could work if your goal is to just create a small application for in-house functions, such as back-office tasks. It’d be quicker and easier to develop, and if you keep the app lite or skim in terms of features, it’ll be easy to maintain as well. The latter point is especially key if your company only has a small team of developers.
But if you expect your application to sustain lots of users and take on a growing set of new features and services, then start with microservices.
Yes, it could be costlier to develop for a start, but pushing it off would mean taking on technical debt. That debt will result in other costs down the line, rendering any upfront savings irrelevant.
Why Microservices?
As noted above, microservices-based applications are costlier to develop upfront, but they come with many advantages suited for the needs of large-scale deployments.
With a microservices application, you can cut the time it takes to release new updates. You’re deploying multiple services independently of each other. This lets you update each separately without the need to wait on the others.
You can also scale individual features to meet demand. So if Netflix’s search service sees more use, Netflix can dedicate more resources to that service and its specific resources.
Finally, you can also avoid cascading failures with microservices. So if a specific service fails, only that one will fail, it won’t cause the entire application to fail.
Changing From Monolithic Architecture to Microservices
Be it as a new application or a legacy modernization project, you should follow these best practices when implementing a microservices-based application.
- each microservice should be to one single data source (it should only control one table).
- each microservice should only do one thing, and do that one thing well. However, you should also stay away from nano-services (i.e., breaking each service into sub-components) — going too small becomes inefficient, maintain a balance.
- when you build microservices, they should be in a bounded context. So one microservice should handle each context, such as the sales context (e.g., order, cart, etc) and support context in an e-commerce application.
- with microservices, you should favour re-writing over re-usability. Let’s say you have two or more microservices with common elements, you should re-write them to be different than to try having them share the same logic across multiple applications.
Whenever you split a monolithic to microservice — just think of the below points.
- Plugin/Play -> Anyone can call -> Multi tenant architecture support
- Operation -> None of the other should fail surprisingly - they should gracefully fail
- Microservice communication -> Asynchronous as well as synchronous
- Independent development and deployment should be possible
- Testing -> stub testing possible
- Microservice will have a defined definition, entities, scope -> segregated responsibility
