<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>c-fe</author><text>I am working on a project that uses a microservice architecture to make the individual components scalable and separate the concerns. However one of the unexpected consequences is that we are now doing a lot of network calls between these microservices, and this has actually become the main speed bottleneck for our program, especially since some of these services are not even in the same data center. We are now attempting to solve this with caches and doing batch requests, but all of this created additional overhead that could have all been avoided by not using microservices.&lt;p&gt;This experience has strongly impacted my view of microservices and for all personal projects I will develop in the future I will stick with a monolith until much later instead of starting with microservices.</text></item></parent_chain><comment><author>strictfp</author><text>Yes. If you design a distributed system you need to consider the network traffic very carefully, and choose your segmentation in such a way that you minimize traffic and still achieve good scalability.&lt;p&gt;For this reason, I&amp;#x27;ve been trying to push for building a monolithic app first, then splitting into components, and introducing libs for common functionality. Only when this is all done, you think about the communication patterns and discuss how to scale the app.&lt;p&gt;Most microservice shops I&amp;#x27;ve been in have instead done the naïve thing; just come up with random functionally separate things and put them in different micro services; &amp;quot;voting service&amp;quot;, &amp;quot;login service&amp;quot;, &amp;quot;user service&amp;quot; etc. This can come with a very very high price. Not only in terms of network traffic, but also in debuggability, having a high amount of code duplication, and getting locked into the existing architecture, cementing the design and functionality.</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>c-fe</author><text>I am working on a project that uses a microservice architecture to make the individual components scalable and separate the concerns. However one of the unexpected consequences is that we are now doing a lot of network calls between these microservices, and this has actually become the main speed bottleneck for our program, especially since some of these services are not even in the same data center. We are now attempting to solve this with caches and doing batch requests, but all of this created additional overhead that could have all been avoided by not using microservices.&lt;p&gt;This experience has strongly impacted my view of microservices and for all personal projects I will develop in the future I will stick with a monolith until much later instead of starting with microservices.</text></item></parent_chain><comment><author>padjo</author><text>I don’t mean to be snarky but how is that an “unexpected consequence”? Were the pros and cons just never considered when deciding to use micro services? Additional networks calls are one of the most obvious things to go on the cons list!</text></comment>