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.
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:
> Microservices had been sold to us [...]
It seems no one really understood the benefits or costs--somewhat understandable as there's no learning better than doing.
> Building on top of a third-party impacted how we could divide our domain into microservices.
Usually the features come together at the top where the user is, in this case it may be both the top and bottom.
> 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
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.
> We have approximately 12 developers spread across 2 feature teams
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.
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.
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.
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.
And the same can happen with software. What goes into a service must be consistent and make sense.
4 comments
[ 3.8 ms ] story [ 9.6 ms ] threadThat 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.
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
The project can be done by a small dedicated team though.
Many teams require support past development life cycle, so I could see a small team upgrading and passing support back to the original product owners.
It seems the politics for this type of move was too costly, I guess.
> Microservices had been sold to us [...]
It seems no one really understood the benefits or costs--somewhat understandable as there's no learning better than doing.
> Building on top of a third-party impacted how we could divide our domain into microservices.
Usually the features come together at the top where the user is, in this case it may be both the top and bottom.
> 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
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.
> We have approximately 12 developers spread across 2 feature teams
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.
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.
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.
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.
And the same can happen with software. What goes into a service must be consistent and make sense.