HalvarFlakeMay 5, 2023

There's a lot of microservices hate, but there are also terrible balls of yarn. It reminds me that many orgs are not good at engineering.

A few rules that have served me well:

1) architect your software, have a diagram.
2) centralize responsibilities in the diagram.
3) not every box in that diagram needs to be a service, some boxes should be shared libraries
4) conversely, not every box should be a shared library
...

Show threadHalvarFlakeMay 5, 2023
...
5) There are two primary reasons to make a box a service: you need parallelism for a box that one machine cannot do, or the box is used by many other boxes and manages state. (Plz reply if you know other good reasons, my list is incomplete)
6) if you do your work right, making a library into a service and vice versa isn't a huge endeavor.
7) the reason monoliths get a bad rap is because people throw sensible abstraction layers away and get a terrible balls of yarn
...
Show threadEleanor SaittaMay 5, 2023
@HalvarFlake
That said, broadly agree. I think there are reasons around release decoupling, mutability, etc. why it can be useful to decouple more, but only in contexts where your developer team isn't mature enough to treat library call boundaries with the same care that they treat service calls. Sadly, this seems to be most teams.
Show threadChristoph PetrauschMay 5, 2023
@dymaxion @HalvarFlake my experience is, that developers who doesn't treat libraries with care, don't apply any care to networked service calls and the possible failure scenarios.
Show threadEleanor Saitta
@hikhvar
Yes and no. Yes, tightly-coupled teams gonna write tightly-coupled code, but there's more expectation of having to deal with out-of-sync version changes with services.
@HalvarFlake
May 5, 2023 at 8:07amWeb