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 threadChristoph Petrausch

@HalvarFlake reasons for 5:

Splitting your boxes in a service, helps you to avoid leader election, or limit the leader to a very small part of the code base. In a previous job we had a lot of "stateless data plane services" controlled by few instances of a control plane. Only the control plane required leader election.

A box is a service, because they are managed by different teams with very different release cadences.

May 5, 2023 at 5:10amWeb