Myth - “Microservices Is The Only True Way”
Why are microservices the default way of developing cloud native applications ? Why does application Modernization in the form of decomposing monoliths result in so many microservices ? Why has microservices become the default deployment model for applications in spite of enterprises struggling with the observability, complexity and performance of the distributed system. Heisenbugs abound when you mix sync and async flows further compounded by various forms of async event driven architecture like thin events, thick events, event sourcing, CQRS etc.,
Frustrated by the intractability and cognitive overload of monoliths, I was one of the first people to ride the monoliths to the microservices wave. However six years after the Microservices article came out from Martin Fowler and James Lewis came out, it is time to retrospect on reality. Have Microservices got you down ? Are you swimming in a mess of brittle microservices that break every night ? Are the number of microservices going up resembling the death-star architecture ? It behooves us to travel upstream and examine the motivations for microservices. How do we peel back the onion and get back to sanity around microservices. How do we rationalize microservices ?
So what is the path forward ? Throw the baby out of the bathwater and swing back to Monoliths. There ought to be a middle way where we can take best of the microservices advantages like domain based composition, enforced module boundaries, independent evolvability, better cognition etc. It is time to look after life after running microservices architectures in production and learn from the mistakes committed over the past five years.
There is a way that has emerged from working with a number of customers where the value of microservices has not been realized from application modernization despite leveraging Domain Driven Design and doing all things right. This process adds sanity to the process of constructing microservices and provides guidelines and design heuristics on structuring microservices. We need to tackle this problem from a technical, business and social perspective marrying concepts from DDD with Wardley Business Maps and Sociotechnical architecture. Rationalize microservices into modular monoliths based on technical and business heuristics. Employ techniques which are a combination of mapping microservices to core technical attributes reduced by affinity mapping and business domain context distillation. This workshop/process called micro2monp has simplified enterprise architectures and improved the operational burden of microservices. You can find more details of the process here and six-factors and post.
So How DO you Rationalize your microservices ? Here is a presentation that walks through all the factors that should be used for rationalizing Microservices.
So How DO you Rationalize your microservices ? Here is a presentation that walks through all the factors that should be used for rationalizing Microservices.
