Micro-services are not a magic bullet.<p>That said a it's fairly common too have need to cross services -- to have something aware of all services to coordinate some aspect. That thing, itself, could be a micro-service that helps you split up everything else.<p>Of course, it's much easier to build as a micro-service than to convert to micro service. It sounds like this article had a lot of coupled services to start with, so going to micro-services was not just isolating components but rewriting a lot of business logic
There were a number of red flags indicating that microservices were not a good fit here:<p>> Microservices had been sold to us [...]<p>It seems no one really understood the benefits or costs--somewhat understandable as there's no learning better than doing.<p>> Building on top of a third-party impacted how we could divide our domain into microservices.<p>Usually the features come together at the top where the user is, in this case it may be both the top and bottom.<p>> We couldn’t identify any obvious candidates in our monolith to be broken out into a microservice. So instead, we started drawing arbitrary lines between our domain models<p>This is how most first-time microservices designs fail drawing boundaries around 'nouns'. With each being a source of truth for information needed in many contexts. A microservice should be one of these contexts and the data it needs from each 'noun' source separately from serving requests.<p>> We have approximately 12 developers spread across 2 feature teams<p>This is the biggest red flag. The primary advantage of microservices is for scaling teams so each can deliver independently. With only 2 pizza-sized teams there's not much point.<p>There may still have been a useful feature that could be extracted into a microservice if given more consideration. Think along the lines of 'what has to change a lot for a particular recurring reason' might point somewhere. Another way is if there's a mixture in the tech stack, e.g. search is often split off.
If you run a book store, it is a good practice to define some way to categorize your books.<p>But what if you pick a weird criteria for categorization and end up with 10000 different sections? That is almost as bad as having each book have its own category.<p>What if you consistently end up with books that are fundamentally different in every way in the same categories? that's almost as bad as completely random categories.<p>And the same can happen with software. What goes into a service must be consistent and make sense.