3 ms·

My favorite microservices pattern is having lots of separate little services, so you get that sweet overhead and complicated debugging, with a shared database,

My favorite microservices pattern is having lots of separate little services, so you get that sweet overhead and complicated debugging, with a shared database, so you can still enjoy systemwide single points of failure and obscure side effects on data.

itsmeste 4y ago
Have those microservices use different patterns (language, framework, infra, etc), and outnumber your devs by a magnitude so everybody gets a piece of that sweet context switching, multiple times a day.
- dopidopHN 4y ago
  Last job I had to ask to confirm the number: 124 services. And it does not work very well. My team was hired to contains and replace it. We ended up with 3 service. Exact same API is provided. It does not matter : nobody is using it anyway !
wrldos 4y ago
Ah I am gorging myself financially on exactly that form of sweet misery.
majormajor 4y ago
I was complaining recently to a manager at another company about a half-assed "microservice breakout" project in a previous job where some teams moved from one big service + one big DB to many big services + single DB and introduced fun new DB connection + perf issues... and was dismayed to learn that this other manager didn't even think "a bunch of services all talking to the same giant DB" seemed like best practices.
mypastself 4y ago
Add to that an existing monolith that’s only been partly migrated to microservices and brother, you’ve got a stew going.
Scubabear68 4y ago
Yep. Have also seen this coupled with the microservices pattern of having all the microservices share a large common library, with all microservices built together and deployed together all the time. All the pain of shared code across teams plus the pain of shared DB plus the pain of debugging across completely arbitrary process boundaries.
- karmakaze 4y ago
  Sounds like a cargo-culted monorepo.
- layer8 4y ago
  This can actually make sense when you have loosely coupled services that mostly talk to the database and external systems, and not directly to each other, that have a common domain model (due to the shared database) and common helper libraries, and that you want to be restartable separately, and/or be distributed over several hosts. Of course, the process boundaries should be well-chosen and not arbitrary.

itsmeste 4y ago

Have those microservices use different patterns (language, framework, infra, etc), and outnumber your devs by a magnitude so everybody gets a piece of that sweet context switching, multiple times a day.

dopidopHN 4y ago
Last job I had to ask to confirm the number: 124 services. And it does not work very well. My team was hired to contains and replace it. We ended up with 3 service. Exact same API is provided. It does not matter : nobody is using it anyway !

wrldos 4y ago

Ah I am gorging myself financially on exactly that form of sweet misery.

majormajor 4y ago

I was complaining recently to a manager at another company about a half-assed "microservice breakout" project in a previous job where some teams moved from one big service + one big DB to many big services + single DB and introduced fun new DB connection + perf issues... and was dismayed to learn that this other manager didn't even think "a bunch of services all talking to the same giant DB" seemed like best practices.

mypastself 4y ago

Add to that an existing monolith that’s only been partly migrated to microservices and brother, you’ve got a stew going.

Scubabear68 4y ago

Yep. Have also seen this coupled with the microservices pattern of having all the microservices share a large common library, with all microservices built together and deployed together all the time. All the pain of shared code across teams plus the pain of shared DB plus the pain of debugging across completely arbitrary process boundaries.

karmakaze 4y ago
Sounds like a cargo-culted monorepo.
layer8 4y ago
This can actually make sense when you have loosely coupled services that mostly talk to the database and external systems, and not directly to each other, that have a common domain model (due to the shared database) and common helper libraries, and that you want to be restartable separately, and/or be distributed over several hosts. Of course, the process boundaries should be well-chosen and not arbitrary.