> I once worked at a place with more micro services than engineers.

Currently consulting somwhere with 30 services per engineer. I cannot convince them this is hell. Maybe that makes it my personal hell.

"Its like family here!"

In that every night you're playing murder mystery, and its never fun.

I would never trust my family with system design either.

as a person that never touched webdev, I have a question

how is such service spam different from unix "small functions that do one thing only" culture?

why in unix case it is usually/historically seen as nice, while in web case it makes stuff worse?

There are so many failures in microservices that just can't happen with a local binary. Inter-service communication over network is a big one with a failure rate orders of magnitude higher than running a binary on the same machine. Then you have to do deploys, monitoring, etc. across the whole platform.

You will basically need to employ solutions for problems only caused by your microservices arch. E.g. take reading the logs for a single request. In a monolith, just read the logs. For the many-service approach, you need to work out how you're going to correlate that request across them all.

Even the aforementioned network failures require a lot of design, and there's no standardization. Does the calling service retry? Does the callee have a durable queue and pick back up? What happens if a call/message gets 'too old'?

Also, from the other end, command line utils are typically made by entirely different people with entirely different philosophies/paradigms, so the encapsulation makes sense. That's not true when you're the one writing all the services, especially not at small-to-mid-size companies.

Plus, you already can do the single-concern thing in a monolith, just with modules/interfaces/etc.

Oooof that's rough.

One strategy to convince is to get someone less technical than you to sit by you while you try and trace everything from one error'd HTTP request from start to finish to diagnose the problem. If they see it takes half a day to check every call to every internal endpoint to 100% satisfy a particular request sometimes that can help.

Also sometimes they just think "this is a bunch of nerd stuff, why are you involving me?!" So it's not foolproof.

Oh, my non-technical boss agrees with me already. It's actually the engineers who've convinced themselves it's a good setup. Nice guys but very unwilling to change. Seems they're quite happy to have become 'experts' in this mess over the last 5-10 years. Almost like they're in retirement mode.

The real solution is probably to leave, but the market sucks at the moment. At least AI makes the 10-repos-per-tiny-feature thing easier.

We pride ourself on 9 5s!

seven nines? That's nothing , bro we got twelve eights!

I have Royal flush :)