[kid_atticus]

At my previous workplaces: no it has always been an unmitigated disaster. And in one case I think moving from the original monolith to microservice based architecture killed the business.

At my current workplace: yes! We have about a dozen separate "microservices" and it works pretty well actually. The main difference I can see is that the boundary layers are extremely well defined and completely asynchronous. There are no synchronous REST or RPC calls between services at all. And it actually works!

I think the key is loose coupling in the extreme.

[ratww]

Exact same experience here.

At my previous workplace it was a disaster.

They hired too many developers in order to grow, and that led to too many people working on the same codebase. Microservices were adopted to solve that. After two years our product was exactly the same as before, except it had much more issues with latency and errors. Headcount was many times bigger, though.

The problem was microservices being adopted for political rather than technical reasons. They wanted teams to own their stuff, but the boundaries were too fuzzy.

We had a lot of duplicated data because leadership never decided which team owned what. Also, some features had to be made by duplicating data in two different services: if team #2 couldn't convince team #1 to send certain events to their microservice, team #2 had to duplicate the whole DB table using Kafka (Very appropriate, right?) and do a cron job.

Another problem happened was when they banned "microservices" but asked to make "well-sized services". New teams had a limit of how many services they could have and to get around the limitation they started having to mix completely unrelated functionality in a single microservice (and yep, that was sanctioned by leadership).

My current company has Microservices, but they exist purely for technical reasons and are extremely loosely coupled, so it works great.

[radicalbyte]

Before anyone even touches "microservices" they should be forced to read Domain-Driven Design. If you do not have a "Bounded Context" and are not splitting your "microservices" by that then you're doing it very wrong.

A lot of the benefits I've seen people using "microservices" to fix what are just horrible design issues in their framework / codebase of choice.

[matt-attack]

Is that a book? Would love a reference.

[andrenth]

Domain-driven design by Eric Evans is the usual reference. There are some other well-regarded books on the subject too, e.g. by Vernon Vaughn.

[andrewstuart2]

> I think the key is loose coupling in the extreme.

Yeah, I agree for sure. I think that's kind of the key whether you're building a distributed system or a monolith, though. e.g. built on small interfaces that are easy to implement. In general, I think the thing about microservices is that they're a lot more sensitive to initial direction because of the added complexity of major architecture changes.