<story><title>Why Segment Went Back to a Monolith</title><url>https://www.infoq.com/news/2020/04/microservices-back-again/</url></story><parent_chain><item><author>nickcw</author><text>I think that the problem here was that they were fighting against Conway&amp;#x27;s Law: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Conway%27s_law&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Conway%27s_law&lt;/a&gt;&lt;p&gt;&amp;gt; Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization&amp;#x27;s communication structure.&lt;p&gt;I think microservices work well in organizations that are big enough to have a team per microservice. However if you&amp;#x27;ve just split your monolith up and have the same team managing lots of microservices you&amp;#x27;ve made a lot more work for the team without the organisational decoupling which are the real win of microservices.&lt;p&gt;In my experience it is really difficult to fight Conway&amp;#x27;s law, you have to work with it and arrange your business accordingly.</text></item></parent_chain><comment><author>kitd</author><text>As with a lot of things, it comes down to communication. Between teams, and between the services they write. Which is just another expression of Conway&amp;#x27;s Law.&lt;p&gt;IIRC Fred Brooks pointed out that the # of bugs in a system correlates closely with the # of lines of communication within and between the teams. Joshua Bloch recommends in &amp;quot;Effective Java&amp;quot; that, if possible, 3 potential clients should participate in the design of an API, for the same reason. So a well-designed interface or OpenAPI spec is worth its weight in gold.&lt;p&gt;Ofc, &amp;quot;microservices&amp;quot; here means separate running instances available on a network. But monoliths can be &amp;quot;service&amp;quot;-oriented as well. OSGi was good for this in Java, but any system able to load shared objects or plugins dynamically can follow the same pattern. And the benefit is that, if your app hits the jackpot and needs to scale outwards, the service interfaces, ie the lines of communication, are already well-defined.&lt;p&gt;So, service-oriented monolith first, then microservices if needed.</text></comment>
<story><title>Why Segment Went Back to a Monolith</title><url>https://www.infoq.com/news/2020/04/microservices-back-again/</url></story><parent_chain><item><author>nickcw</author><text>I think that the problem here was that they were fighting against Conway&amp;#x27;s Law: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Conway%27s_law&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Conway%27s_law&lt;/a&gt;&lt;p&gt;&amp;gt; Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization&amp;#x27;s communication structure.&lt;p&gt;I think microservices work well in organizations that are big enough to have a team per microservice. However if you&amp;#x27;ve just split your monolith up and have the same team managing lots of microservices you&amp;#x27;ve made a lot more work for the team without the organisational decoupling which are the real win of microservices.&lt;p&gt;In my experience it is really difficult to fight Conway&amp;#x27;s law, you have to work with it and arrange your business accordingly.</text></item></parent_chain><comment><author>andy_ppp</author><text>Yeah, the problem with microservices is because the organisation structure is wrong. I’ve literally heard every excuse about microservices at this point. My architecture is better but it doesn’t have a snappy name; it’s called the smallest possible number of services that can be reasoned about and network partitions are NOT necessary to create bounded contexts in a codebase, often just a directory is FINE.</text></comment>