> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/general-paradigms/architecture/module-patterns/module-monilith-microservice.md). # Module monolith vs Microservices * Trend of always going for microservice rather than monolith, with out considering the implications * Better to think of mircoservices as the end goal, and start with modular monolith * The main benefit of microservices that people promote is * the idea of creating and maintaining small, independent "chunks" of code and data, versioned apart from one another, using common inputs and outputs to enable a larger integration of the system. * But modules allow the samething, with less of the issues of microsevices * But the main benefit of microservices is * organizational clarity * development team aggregating ownership of any and all of those dependencies that could (and frequently would) block them from moving forward. * each team could build their artifact independently of one another * When the teams grow * Issues * hiring these folks became infinitely trickier, need to hire bigger skillset * Independently scalable * it's a critical factor * Independent releasability * Need to use diverse technologies to support business needs * Allows for greater flexibility * Manage complexity of the domain * Main issues * * When passing that data across network lines, though--as most microservices do--adds five to seven orders of magnitude greater latency to the communication * maintance - monitoring * each service must be deployed independently, which increases the technical and operational complexity * experience performance issues as a result of ‌increasing network traffic between services. * With increasing complexity, microservices might be more susceptible to mistakes and defects as well. * Hard to get right * lot of complexity ## Modular monolith * A monolithic architecture is a singular, large computing network with one code base that couples all of the business concerns together. To make a change to this sort of application requires updating the entire stack by accessing the code base and building and deploying an updated version of the service-side interface. * A Modular Monolith consists of dividing logic into modules, as each module is independent and isolated. * Every module is in charge of its own business logic, database or schema, etc. * With this model of architecture, you can build and modify existing layers of each module while leaving the others unaffected. * Modules should communicate through APIs, allowing access to the logic of each module through public methods, not internal functions and the logic of each one. * ## Benefits of modular monolity * Modules circumvent a lot of the issues * when a system is decomposed into in-memory modules running on a single operating system node, the costs of passing data across process or library boundaries is pretty negligble * improve stability and perforamnce * Faster to develop * few moving parts, which makes it easier and quicker to accept modifications. * Simpler to create, deploy and manage * the modules are produced and delivered as a single unit, which makes the application significantly easier to design, deploy and manage * Cost effective * Owns it's persistance * smaller domain model, bounded context * improved encapsulation * use of exposed api ## disadvantage of monolith * how slow the development velocity is. Adding new features is slow because there is a large cognitive load on the developer. * Modules of monoliths are tightly coupled, which can significantly lengthen the release cycle of a monolith. * Need to have mechanism to prevent this ie use of arch unit * when splitting a monolith * Difficulties in finding boundaries * Decoupling data, splitting tables * speed of tests * Shared transactions * An exception in a module you call/notify can rollback your transaction * Resource starvation * Modules shared thread/db connections pool * Need good monitoring * Deadlocks * in process or out process * Single instance of DI container * global settings, rogue aspects, bean name collisions * Unified Openapi * single version * type name collisons * End to end tests are slow * multiple modules involved * prefere module scoped tests * Always ready to ship * need to use feature flags * Builds can be long * parallalise ## Monolith to microservice * trying to turn a poorly structured monolith into a distributed architecture will only get you a... poorly structured, yet distributed architecture. * Easier to go from modular monolith to microservice ## Links * Modules or Microservices? - Sander Mak * * * The Modular Monolith - a Practical Alternative to Microservices by VICTOR RENTEA * *