Microservices — Are you jumping on the bandwagon?

“Microservices” A buzz word in the current software development era and had been in the spot light since a decade now.
When it comes to Microservices, a lot has been said and written to advocate why we should use them and what are the benefits. Though I am not in a denial that they are very useful but not everyone fits the mold. So for a specific problem statement in a particular business context the more important and probably the first question that has to be asked is “Do I need Microservices for THIS?” rather than to jump on the bandwagon.
How to find out if Microservices architecture is the best choice for you? While there are many factors those have its own importance, following are paramount -
- Complexity — As Martin Flower quotes “don’t even consider microservices unless you have a system that’s too complex to manage as a monolith”. Whether it is a new system that needs to be developed or an existing one, assessing it’s complexity will throw some light if Microservices are needed. A simple or moderately complex existing system which is stable and doing what is supposed to do and doesn’t need any scalability, is definitely not a good candidate to be redesigned. Microservices itself brings a lot of additional factors to be considered in terms of design, management, deployment and maintenance.
- Not Big Enough — A system which is already loosely coupled and have flexibility in deployment, like designed with SOA may already have services communicating with each other and modular enough to be broken down further. Redesigning with Microservices may not give as much as benefit as the magnitude of complexity and overhead introduced.
- Domain Model — In certain situations where the domain model is not clear enough its difficult to define boundaries well in advance that microservices will adhere to. Once the model changes (Change in the domain model should not be attributed to agility and scalability) its hard to renegotiate the contracts, either too much refactoring or lot of duplicate code and data happens. New dependencies surfaces up and so on. Successful adaption of Microservices architecture highly depends on the right design of Microservices which starts with a defined domain model and boundaries.
- Cost — For an existing monolith system which is not huge and complex, communication between different layers will be straight and optimized. Even a small team which is familiar with the system will be able to maintain it with less overhead compare to if it is broken into Microservices since Microservices will bring a lot of operational cost associated with it in terms of time, efforts and resources.
- Legacy Systems — Legacy systems are established reality. Many organizations have legacy systems and which are running next to perfection for them in their day to day operations. Even they don’t look as beautiful and well crafted but might be doing some mission critical task. So before redesigning them with Microservices a long term strategy with a well defined plan of migration has to be in place. Organization’s readiness should also be assessed before commencing.
- Monolith By Nature — There are systems that are monolith by nature, means they have been developed that way since they needed a tightly coupled layers of communication and adding any additional layer/wrapper may introduce a delay in response time. Usually embedded systems have been that way. This kind of systems are also not a good candidate for Microservices architecture in general.
- Organization’s Fit — Once all other factors are taken well into consideration, the last but certainly not the least is to zoom out and see if the organization is ready to shift architecture and is well equipped to start and to carry on the Microservices architecture transformation. This is simply not a mere technology implementation, rather it needs a whole lot and few of them are cultural shift, expert resources, right infrastructure, autonomous teams and a right mind set.
So the gist is to analyze your need first and then if you find Microservices to be the right fit, go ahead. Microservices are very powerful and gives many unmatched benefits (with few trade-offs, no surprise).