
Why our team cancelled our move to microservices - jose_zap
https://medium.com/@steven.lemon182/why-our-team-cancelled-our-move-to-microservices-8fd87898d952
======
ldoughty
Micro-services are not a magic bullet.

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

~~~
nighthawk648
Exactly.

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.

------
karmakaze
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.

------
29athrowaway
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.

