
Goodbye Microservices: From 100s of problem children to 1 superstar - tejohnso
https://segment.com/blog/goodbye-microservices/
======
kostarelo
It seems to me that was a classic case of "Microservices done wrong". Yes,
splitting the destinations to be able to scale independently makes sense but
doing so in different repos AND with shared libraries of business logic, that
is just bad engineering (and I've done that my self, and I'm doing bad
engineering choices every day).

Microservices fits nicely when you have identified the appropriate domains of
your system and you want to give these domains the freedom to take their own
path, independently from the others.

In your case, especially when talking about that many destinations a.k.a.
services, I would have split them up in different deployments, keep them in a
monorepo from the beginning so they can share common infrastructure code (not
business logic) but they would be able to have their own logic so engineers
could change a field in one that wouldn't affect another one (always doing
backward-compatible changes, never removing fields, etc).

We live and we learn. Thank you for your post. :)

------
mikece
How many people are writing microservices just because it's the conventional
wisdom to do so? Probably the best talk I've ever seen on microservices was a
demonstration of how to scale Identity Server to handle authentication for an
app with a billion users. This is highly unrealistic for almost everyone but
the speaker had actually done this (well, at least to 100M users) and the
revelation I had from the talk is to design knowing how you would decompose a
service into microservices IF YOU HAD TO and then respect those boundaries
going forward. You almost certainly won't need to scale like this... but if
you do, knowing how you're going to split up a service into microservices and
respecting those context boundaries will save time now and allow you to scale
to absurdity if you ever need to.

~~~
kostarelo
Unfortunately, it is common. It reminds me of the "let's go with MongoDB even
though we have a relational schema, just because it's easier".

