<story><title>Modules, not microservices</title><url>http://blogs.newardassociates.com/blog/2023/you-want-modules-not-microservices.html</url></story><parent_chain><item><author>gunnarmorling</author><text>I really like modular designs, but this article is missing some key limitations of monolithic applications, also if they are really well modularized (this is written mostly from the perspective of a Java developer):&lt;p&gt;* they force alignment on one language or at least runtime&lt;p&gt;* they force alignment of dependencies and their versions (yes, you can have different versions e.g. via Java classloaders, but that&amp;#x27;s getting tricky quickly, you can&amp;#x27;t share them across module boundaries, etc.)&lt;p&gt;* they can require lots of RAM if you have many modules with many classes (semi-related fun fact: I remember a situation where we hit the maximum number of class files a JAR could have you loaded into WebLogic)&lt;p&gt;* they can be slow to start (again, classloading takes time)&lt;p&gt;* they may be limiting in terms of technology choice (you probably don&amp;#x27;t want ot have connections to an RDBMS and Neo4j and MongoDB in one process)&lt;p&gt;* they don&amp;#x27;t provide resource isolation between components: a busy loop in one module eating up lots of CPU? Bad luck for other modules.&lt;p&gt;* they take long to rebuild an redeploy, unless you apply a large degree of discipline and engineering excellence to only rebuild changed modules while making sure no API contracts are broken&lt;p&gt;* they can be hard to test (how does DB set-up of that other team&amp;#x27;s component work again?)&lt;p&gt;I am not saying that most of these issues cannot be overcome; to the contrary, I would love to see monoliths being built in a way where these problems don&amp;#x27;t exist. I&amp;#x27;ve worked on massive monoliths which were extremely well modularized. Those practical issues above were what was killing productivity and developer joy in these contexts.&lt;p&gt;Let&amp;#x27;s not pretend large monoliths don&amp;#x27;t pose specific challenges and folks moved to microservices for the last 15 years without good reason.</text></item></parent_chain><comment><author>kerblang</author><text>Mostly valid, but...&lt;p&gt;On the RAM front, I am now approaching terabyte levels of services for what would be gigabyte levels of monolith. The reason is that I have to deal with mostly duplicate RAM - the same 200+ MB of framework crud replicated in every process. In fact a lot of microservice advocates insist &amp;quot;RAM is cheap!&amp;quot; until reality hits, especially forgetting the cost is replicated in every development&amp;#x2F;testing environment.&lt;p&gt;As for slow startup, a server reboot can be quite excruciating when all these processes are competing to grind &amp;amp; slog through their own copy of that 200+ MB and get situated. In my case, each new &amp;amp; improved microservice alone boots slower than the original legacy monolith, which is just plain dumb, but it&amp;#x27;s the tech stack I&amp;#x27;m stuck with.</text></comment>
<story><title>Modules, not microservices</title><url>http://blogs.newardassociates.com/blog/2023/you-want-modules-not-microservices.html</url></story><parent_chain><item><author>gunnarmorling</author><text>I really like modular designs, but this article is missing some key limitations of monolithic applications, also if they are really well modularized (this is written mostly from the perspective of a Java developer):&lt;p&gt;* they force alignment on one language or at least runtime&lt;p&gt;* they force alignment of dependencies and their versions (yes, you can have different versions e.g. via Java classloaders, but that&amp;#x27;s getting tricky quickly, you can&amp;#x27;t share them across module boundaries, etc.)&lt;p&gt;* they can require lots of RAM if you have many modules with many classes (semi-related fun fact: I remember a situation where we hit the maximum number of class files a JAR could have you loaded into WebLogic)&lt;p&gt;* they can be slow to start (again, classloading takes time)&lt;p&gt;* they may be limiting in terms of technology choice (you probably don&amp;#x27;t want ot have connections to an RDBMS and Neo4j and MongoDB in one process)&lt;p&gt;* they don&amp;#x27;t provide resource isolation between components: a busy loop in one module eating up lots of CPU? Bad luck for other modules.&lt;p&gt;* they take long to rebuild an redeploy, unless you apply a large degree of discipline and engineering excellence to only rebuild changed modules while making sure no API contracts are broken&lt;p&gt;* they can be hard to test (how does DB set-up of that other team&amp;#x27;s component work again?)&lt;p&gt;I am not saying that most of these issues cannot be overcome; to the contrary, I would love to see monoliths being built in a way where these problems don&amp;#x27;t exist. I&amp;#x27;ve worked on massive monoliths which were extremely well modularized. Those practical issues above were what was killing productivity and developer joy in these contexts.&lt;p&gt;Let&amp;#x27;s not pretend large monoliths don&amp;#x27;t pose specific challenges and folks moved to microservices for the last 15 years without good reason.</text></item></parent_chain><comment><author>lightbendover</author><text>&amp;gt; they force alignment on one language or at least runtime&lt;p&gt;How is this possibly a down-side from an org perspective?  You don&amp;#x27;t want to fracture knowledge and make hiring&amp;#x2F;training more difficult even if there are some technical optimizations possible otherwise.</text></comment>