3 ms·

Goodbye Microservices: From 100s of problem children to 1 superstar

4 points by tejohnso 7y ago

mikece 7y ago
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 7y ago
  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".
kostarelo 7y ago
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. :)

4 points by tejohnso 7y ago

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 7y ago
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".

kostarelo 7y ago

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. :)