I think a big reason is that microservice architecture forces teams to establish clear boundaries rather than leave it to team diligence.

For less centralized organizations, I think it can be a useful forcing function.

Clear boundaries on multiple levels as well. I believe a _very_ big part of why people feel they need microservices is because of poor architecture and a lack of boundaries in a monolith. Every single monolith I've come across has had issues with circular dependencies and no real contracts between "apps" (as they are called in Django).

I believe people see ORMs such as Django's as a way to perform one big query as opposed to many small queries. The big query spans 3 apps and 8 models. You have these things sprinkled throughout the codebase and you end up with a big ball of mud.

But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)?

This situation is a necessary conceptual step before decoupled micro services and far far easier (because it introduces none of the ops problems of microservices).

But that never seems to happen. I think it’s because codebase discipline rules are harder for management to ‘see’ than API rules.

> But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)?

1. One person or group needs to decide on what the rule should be, what the boundaries are and how to enforce those boundaries. This is usually not an easy process, ymmv.

2. After a decision is made, you'll have to decide on how to put the rule in place. Are you going to stop everything and make sure all code paths are working according to the new rule? Are you going to do it incrementally? New features = new rule, old features = common sense? Another variation?

3. You then start running your new rule and maybe you enforce it with some custom static checks, and when that fails you hope your code reviewers will always catch this every time.

4. You still need that one person or group to make sure this actually gets done and to assess if it actually has a positive impact on velocity and reliability.

Or you can put in an implicit "rule" that new code happens in a separate repository, where you don't need to care. A developer that has to do an API call because they simply cannot "import" another module or "query" someone else's data has no choice but to do the right thing - though many opportunities to do a lot of other wrong things too, this is not a panacea. But when we're talking about more than ~5-6 teams, the coordination effort of making sure everyone is aligned on a monolith can be much tougher than to go to multiple services (hopefully not micro).

I think your points are about lacking solid engineering leaders at an organisation that could provide guidance and manage execution of the "modular monolith" approach. If a company does not have leaders who can ensure consistency and discipline across a few team within a monolith, I am afraid of the mess they will run into with multiple services.

None of these problems are solved by microservices. Now instead of undocumented unstructured interactions between modules, you have undocumented unstructured interactions between standalone applications. None of your problems are solved, except now you have a much bigger cloud hosting bill.

That’s not been my experience working with microservices for the past 5+ years. It’s in a team’s own interest to document their APIs and design them well, because if they don’t then it’s their own time sink when other teams integrate.

Microservices have problems but the way they’re often portrayed doesn’t match my experience.

I agree with the sibling commenter who said that a microservices architecture exchanges an organizational expense for a technical expense. For certain organizations, it can be the right call.

I agree though I'd have to think a bit more about the exact way for apps to speak to each other. My guess would be each app could have an api file with a bunch of functions. I wonder how that would work in a situation where you have 3 apps, each with a single model, and the dependencies are A -> B -> C. You could still run into situations where B isn't supposed to know anything about A yet nothing stops B from importing A's api.

It’s still possible to have circular dependencies in microservices. There is normally nothing stopping service A calling B and B calling A except common sense and discipline.

In fact I would say it’s MORE difficult to prevent circular microservice dependency programmatically than in code (where you can hook into module level imports).

The corollary being that the technical problem of a microservice architecture is easier to solve than the management problem of leading a single large team.

Probably some truth to that.

Well said. I think a microservices architecture exchanges an organizational expense for a technical expense. For certain organizations, it can be the right call.

Something to consider: when you then realize that the boundary isn’t the correct one or the environment evolved enough that it isn’t meaningful anymore, that’s really painful and expensive to change.

Microservices and monorepos are unrelated to each other.

You can have 100 micro services from a single repo, and the services are just different folders.

Microservices help people have bounded context when they are develop and they leak their abstractions less into the next one. Monoliths (admittedly I've only seen them in Python, Ruby and .Net) start reaching into each others pieces and adding to tech debt in subtle ways.

You are of course right, discipline is required in both architectures, but there are different emphasis in both.