# 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
    * https://architecturenotes.co/fallacies-of-distributed-systems/
      * 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.
* https://newsletter.techworld-with-milan.com/p/why-you-should-build-a-modular-monolith

## 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 https://youtu.be/siHAu5sIIko
* https://blogs.newardassociates.com/blog/2023/you-want-modules-not-microservices.html
* https://www.cmsdrupal.com/blog/modular-monolith-vs-microservices-how-do-you-make-choice
* https://www.youtube.com/watch?v=nuHMlA3iLjY The Modular Monolith - a Practical Alternative to Microservices by VICTOR RENTEA
  * https://github.com/victorrentea/spring-modulith
  * https://www.slideshare.net/slideshow/modular-monolith-a-practical-alternative-to-microservices-devoxx-uk-2024/267975501
