[laichzeit0]

I’m not saying micro services are terrible at all. But I think the low coupling leads to a lot of “problems” when you try and re-aggregate data for analytics purposes when fundamentally micro services are meant to enable teams to work on them without worrying about how some other micro service is storing its data. It’s a trade off you make.

[Tabular-Iceberg]

> fundamentally micro services are meant to enable teams to work on them without worrying about how some other micro service is storing its data

What exactly is it that microservices bring to the table to achieve that, that doesn't already exist out of the box in every single language in common business use?

[laichzeit0]

It lowers coupling between teams. If my team is responsible for microservice A then I have no dependency on the team working on microservice B. Microservice A writes to its own database. There are no migration dependencies, etc. It's a distributed system. You have to accept that one microservice could be using mongodb, another postgresql, another mssql. You're typically communicating through APIs, one microservice is not reading directly from the database of another microservice. Materializing all this crap when you want to do analytics is where the problem comes in as now you are forced to construct some unified data model.

[Tabular-Iceberg]

> It lowers coupling between teams.

Yes, but you don't need microservices to do that. You can just lower the coupling between the teams working on your monolith using the means of abstraction of the language is written in.

> If my team is responsible for microservice A then I have no dependency on the team working on microservice B.

How is that different from the team responsible for Java package A having no dependency on the team working on Java package B? Or whatever language you happen to use.

> Microservice A writes to its own database. There are no migration dependencies, etc. It's a distributed system. You have to accept that one microservice could be using mongodb, another postgresql, another mssql.

Nothing is stopping you from connecting to multiple databases from the same monolith either.

>You're typically communicating through APIs, one microservice is not reading directly from the database of another microservice.

You can (and should) build well defined APIs between modules in your monolith too. And it's faster than having to keep serializing and deserializing everything all the time.

>Materializing all this crap when you want to do analytics is where the problem comes in as now you are forced to construct some unified data model.

Why do you think you need to unify your data model in a monolith? If you think it's the wrong strategy for your problem all you have to do is not do it.

[dragonwriter]

> Yes, but you don't need microservices to do that. You can just lower the coupling between the teams working on your monolith using the means of abstraction of the language is written in.

Forcing a common platform across unrelated components because you have decided to make it a monolith is tighter coupling than exist with microservices, so, no, you can’t. Choosing a monolith is choosing a higher level of irreducible coupling that choosing independent (not necessarily “micro”) services.

[Tabular-Iceberg]

Maybe I should have called it "oligoliths". I'm not arguing for forcing the entire business to run in the same address space. For example it makes sense to split OLTP from batch processing, since they have different lifecycles. But I don't think that's what most people mean when they talk about microservices.

Whether parts of your monolith are overly coupled or not is purely a design decision. Pay the same attention to the APIs and areas of responsibility between the parts of the monolith as well as you do the microservices and you'll be no worse off. Devs who just can't help themselves and turn every monolith into a mess of spaghetti don't exactly inspire confidence that they will do better with microservices, especially with the added complexity of building a distributed system.