# From Modular Monolith to Micro Service ## James Randall ### Blog - [https://www.azurefromthetrenches.com](https://wwww.azurefromthetrenches.com) ### Twitter - [@azuretrenches](https://twitter.com/azuretrenches) ### Code - [https://github.com/JamesRandall/fromModularMonolithToMicroservice](https://github.com/JamesRandall/fromModularMonolithToMicroservice) ### Slides - [https://jamesrandall.github.io/fromModularMonolithToMicroservice/](https://jamesrandall.github.io/fromModularMonolithToMicroservice/) ----- ## A Bit About Me * Working "Cloud First" since 2011 * Ran a lean startup inside an enterprise (good way to lose hair) * Worked as a consultant in a variety of organisations from enterprise integration through to hyper-scale eCommerce * Currently work as an independent consultant: * Architecture / code consultancy * Problem solving * End to end product / solution development ----- ## What Is A Modular Monolith? * A unit of software that addresses multiple concerns * Internally decomposed into isolated modules or subsystems * Significant proportion of intra-subsystem communication occurs in-process * The modules and subsystems deploy and scale together * A system, as perceived by a customer, may be made up of only one of these ----- ## What Are Micro Services? * A unit of software that addresses a single concern * Deploys and scales independently to other services * Communication with other systems occurs via APIs(REST, queues, events etc.) and usually over a network * A system, as perceived by a customer, may be made up of tens, hundreds or even thousands of micro-services ----- ## Why From Modular Monolith To Micro Service * I spent time working: * With small teams struggling for market fit * In large organisations with hundreds of developers where the primary challenge was scale - technical, volume and organisational * And saw: * Micro services slow small projects to a crawl and become impediments to addressing actual challenges * Micro services help large projects scale - both technically and organisationally * Monoliths help kick start small projects * Traditional monoliths grow from small to large becoming an ever more crippling and frail millstone * Monoliths expensively rewritten into micro services ----- ## Development is a Journey * The needs of a product, system and team change over time * There isn't a "one size fits all" answer, its all about the right tradeoffs * What's beneficial at one point in time can be an impediment at another * Acknowledging that - can we optimise for the journey?

## Typical Monoliths * Tend to use layered architecture (sometimes called onion layer) * Decoupling occurs using interfaces and an IoC container e.g. * StoreService implements IStoreService and makes use of an IStoreRepository implemented by a StoreRepository * As they get larger services begin to rely on other services and things get quite spaghetti like * Cross cutting concerns (e.g. logging) are often: * Implemented as services themselves and injected into other services with each service (ILogger) sometimes using a decorator approach * Or they use features of the container framework (e.g. filters in ASP.NET Core) ----- ## What Are The Downsides of This approach * None of these things are inevitable but: * They have a habit of turning into spaghetti and early attempts to wall off sub-systems tend to break down * It can be difficult to apply generic / abstract code to the per service interface approach * They tend to have a lot of boilerplate * It can be hard to decouple from the container technology ----- ## Creating A Modular Monolith that Can Evolve Into Micro Services * Express operations using state * Use assemblies and access modifiers (public, internal, etc.) to define boundaries that are enforceable through easy static analysis * Communicate (sub-system) operations through a mediator * Describe sub-system communication using configuration * Reduce boilerplate by addressing cross-cutting concerns with the mediator * Avoid coupling cross-cutting concerns, where possible, to container frameworks - keep them portable

# Code! ----- # Decomposing Into Micro Services * To demonstrate how the approach we've adopted can facilitate decomposition into isolated services we'll pull out the notification and product subsystems * To keep things clear this example is slightly artificial: * I have kept things in a single solution * I have used project references * In a real world solution each subsystem would be: * Isolated in its own git repository * Expose API contracts as swagger documents, JSON schema, and/or NuGet client packages

# Code! ----- ## Summary * When designing a system consider your current challenges, capabilities, and likely direction of travel * Expressing operations as state allows for a great deal of flexibility * Focus on being DRY and cleanly separating concerns - it will make it easier to evolve your system -----