Microservices in the last few years has become a hackneyed concept and the modus operandi methodology for building applications to drive digital transformations. The so-called adoption of modern Hydra with tentacles to replace the legacy one-eyed Cyclops seems what most organizations are striving towards when strategizing Modernization, Cloud adoption journeys or Agile and DevOps ways of working.
After spending few years learning and understanding the platform revamp of moving away from a bulky monolithic commerce platform to service-based architecture, I have learned myriad ways on how IT organizations bungle up a journey and at times come a whole full circle.
There is no direct method to this madness but for sure are best practices and learning from earlier blunders and possibilities to circumvent hidden traps and pitfalls.
The Onset Enigma
The inception of the microservices journey is typically to combat the imponderable conundrums pertaining to “Slow time to market”, “Complex and heavily customized applications”, “Testing nightmares”, “Scalability and Stability issues”, “Velocity,” “Technology binding”, “Adopting modern stacks”, “Continuous Integration and Continuous Delivery”, “Cost factor” and locking vendor licensing model” and the list goes on.
Microservices approaches differ from organization to organization and there is no ready-made panacea. I have time and time seen teams perform a mere replication of these approaches resulting in incurring insurmountable technical debt.
Before embarking on a microservices journey, it’s essential to comprehend what issues one is trying to deal with and where one needs to start?
A lot of initial time has to be spent to understand the “complexities of the existing monolith”, “core issues with the legacy”, “technology forecast”, “business limitations”, “future business requirements”, “organization processes”, “their strengths and weaknesses, “team sizes”, “operational readiness” “ways of working” , “cultural standpoint”, “integration dependencies” and several other factors before choosing an approach.
It’s pretty common to see that modern IT teams yearn for re-architecting existing monolithic applications and move away from the mundane system to a more services-oriented modern stack and technology.
But, before even attempting the journey, teams need to evaluate if the journey is worth the endeavor? Typical questions teams need to ask themselves
- Maybe the release cycles of the monolith are of way too less frequency and just leaving it alone is the best solution?
- Maybe the monolith is of a specific size and estimated to not grow further?
- Maybe the organization is not ready yet to begin the journey from an operational, technology, process or even from a cultural point of view?
- Maybe there are way too many features in the monolith that is more crucial from a business and cost standpoint?
- Maybe the monolith has a short lifespan and is getting replaced?
- Maybe the organization is not yet agile or has not yet adopted DevOps which is pivotal for a microservices journey?
- Maybe breaking the monolith is way too complex and it is easier to rewrite code from scratch using new software?
- Maybe building new features is of more priority than breaking out new services?