Great advice. Microservices also open the door to polyglot, so you lose the ability to even arrive that everyone uses/has access to/understands the things in a common libCompany that make it possible for anyone to at least make sense of code.
When I talk to people who did microservices, I ask them "why is this a service separate from this?"
I have legitimately - and commonly - gotten the answer that the dev I'm talking to wanted their own service.
While I see your point about the downsides of involving too many languages/technologies, I think the really key distinction is whether a service has its own separate database.
It's really not such a big problem to have "microservices" that share the same database. This can bring many of the benefits of microservices without most of the downsides.
Imo it would be good if we had some common terminology to distinguish these approaches. It seems like a lot of people are creating services with their own separate databases for no reason other than "that's how you're supposed to do microservices".
Microservices with their own database are often a terrible design choice, but I will grant you it is one of the two dimensions that make sense:
1. is there a _very significant_ difference in the horizontal scaling footprint/model or demand (and demand is _only relevant_ if there is static footprint)? Home the function with a similar service, if there is one, otherwise yes, add a service.
2. is there a _genuine_ and _legitimate_ need for a different database, with completely independent schema, and not some horrible bullshit where you will end up doing cross-party transactions (and almost always failing to do so well)? Are you sure you need a different database or is your team just afraid of SQL and schema management (the usual mongodb garbage)? Is the issue that you don't understand how database security works? .. if all of these pass muster, then yes, ok, that's an OK reason.
Every architecture I've seen since 2013 at startups and big companies alike (since I do technical diligence professionally as a side gig) has been microservices or simple CRUD.
Almost all of the microservices ones were totally fucking wrong and had to be massively reworked, and usually multuple times, because they had no thesis at all for what they were doing and it was often - even mostly - an excuse not to have to learn their tools beyond tutorial level and/or a desire to play with new shiny or not read someone else's code. The CRUD guys were fine, they just did business until they needed to add caching, and so on, like real products.
When I talk to people who did microservices, I ask them "why is this a service separate from this?"
I have legitimately - and commonly - gotten the answer that the dev I'm talking to wanted their own service.
It's malpractice.