Below mentioned points try to summarize some of the basic idealogies that need to be followed and thought through before we take up any monolith to be migrated to a bunch of microservices.
- Have a very clear reason on why you are moving to microservices – Unless there is a use-case that gets satisfied its better to stick around with Monolith. Just going with the trend and moving to microservices may not be a great business decision.
- Always chip away at your monolith – Do not do a big bang rewrite to move to microservices. It has to be iterative. Taking remediation measures are easy when there are smaller steps involved.
- Its not about duplication – You do not move to microservices to promote reuse. Reuse may or may not be a side effect of moving to microservices. But definitely not the driving reason.
- Always start with low hanging fruits – By this I mean that we should first carve out services that are easy to be converted into a microservice. There are multiple benefits of doing this. We can show results early on. Take learnings early on. The team which is doing the movement will be able to gain confidence and enhance their technical know how around microservices early on before picking up any complex task.
- Start by breaking your code into modules – Breaking up source code into modules would help formulate the various boundaries that are necessary to arrive at a microservice. Modular code makes it much more clearer and easier to pull out microservices from a monolith.
- Understand trade offs – If you are trying to solve a problem with microservices, it would most probably come at a cost to some other aspect. For example, network hops. A microservice architecture is definitely going to have more network hops than a monolith it was migrated from.
This list is not exhaustive. So, don’t be surprised if there are updates to it over time.
I can be reached at @simranzchawla