On a large/quickly growing team the risk is folks begin to not respect the modularity and you end up with just a regular monolith

Perhaps formalized abstractions around these barriers is a good idea? At the very least better than the 60 kubernetes services at my 100eng headcount team? :-)

One major criticism I have of the way modules work in many stacks is that the dependencies between modules are hard to visualise and/or manage. Certainly in the C#/.NET world it's very easy to accidentally end up with one module depending on another that depends on the initial module via some chain of dependencies. And it's too easy to add extra dependencies to some low-level module that's supposed to be a "core" base layer module that's used across the board. That's less of a problem with microservices, esp. in a multi-repo environment, where you can enforce boundaries more easily. It's one of the few points in favour of microservices, from what I've observed so far - that you can safely make a change to a particular microservice and know a) it's definitely not going to break the CI/CD pipeline for the rest of the product b) if you have introduced a bug, there's typically very limited impact it can have.

Exactly. On the JVM (at least, dunno if C#/.NET has a similar mechanism) you can technically get away with using OSGi which can load things into separate classloaders along with all implementation-dependencies such that you can truly separate the API of a dependency from its implementation.

Alas, support for OSGi in the general ecosystem is abysmal, and the next best thing seems to be microservices.

Honestly, I find it pretty shocking that so many mainstream languages don't support this sort of "local isolation" better. The diamond dependency problem well-known at this point.

(To be clear, in our shop we generally only do this for very problematic dependencies that have a tendency to break backward bincompat on a whim. Those are almost always the most painful ones, especially if they are in turn dependended on by many of your project's other dependencies.)

Spring Modulith is trying to enforce strict module boundaries.

I haven't yet tried it myself, but it looks promising:

https://spring.io/blog/2022/10/21/introducing-spring-modulit...

Because all these idiots who pitched microservices super hard need to undo the mess they've created while self promoting themselves into new thought leadership roles.

Uffff

Spot on.

And how do you know you’re not a thought leader? You call yourself one

Yeah, I was just talking to the CEO of a startup that I built the tech for, and still have a small equity stake in.

They formed a partnership with some dev shop that's going to rebuild everything that I made (that's working great and scales well).

I asked her why, and she said "because they say that doing microsevices on Azure is better architecture".

There goes that bit of equity, I guess.

/shrug

That's terrible, so sorry

Is it the fault of the thought leader, or the loads of juniors asked to implement the architecture but don't really understand it? If everyone had better system design knowledge, it wouldn't be so bad. 90% of the engineers in my organization don't understand the function of an API Gateway, for example. So the thought leader does propose a reasonable solution, but then it doesn't work because the organization doesn't have the hard skills necessary to deliver. I'm sure there's other reasons microservice-based architecture fails, but in my experience, this is a primary reason.

I feel this comment might go over people's heads if they take the connotation of a "though leader" as someone who makes a mess of things with overcomplicated solutions and then leverages it to greater roles before the consequences of the mess are discovered.

However, I've definitely seen this problem even with legitimately strong, seasoned technical leadership, where the vision is great, but the team just doesn't have the skills to pull it off. You can't have good macro-engineering without good micro-engineering. The problem with the cambrian explosion of tech is that it obfuscates the basics that engineers need to understand. Junior engineers end up struggling just to stay on top of incidental complexity and many come to the conlusion that building good software is just about learning enough languages and tooling, when in reality they are barely keeping their head above water and never learn the deeper lessons of what works and doesn't in software systems.

> juniors asked to implement the architecture but don't really understand it?

Can you reasonably expect a junior engineer to push back here and generally get traction? If this architectural decision has been made, it’s been made. At higher levels.

>If everyone had better system design knowledge

I don’t think this is a junior devs fault - they’re junior, after all.

> but then it doesn’t work because the organization…

Bingo.

I can think of a few cases. For instance, say you want to make parts of your codebase open-source and self-contained, but others closed-source. It can be easier to carve off the OSS and treat it as if it were a third-party application.

That's not the case here, where the code lives in a monorepo but the services are many.

In that case it would be just as easy to have the OSS app be used directly by the closed source app instead of spinning up another service. It could be a library, a plugin, or even just a separate app that your internal app shells out to. Basically, a separate OSS release really shouldn't be a consideration for deciding to run it as a separate service or not. Though it is an excellent reason for a separate repo.

Mass psychosis.

I love a good modulith.

Most devs, even senior, have no clear idea what a modular monolith is, let alone implementing one

This is a way to modularise a monolith. It just happens to also be a way to allow it to build out to a distributed deployment.

I hesitate to say "microservices" because I strongly suspect that the 95th-percentile use case will see all the parts strongly coupled and deployed as a single commonly-versioned blob. Not saying that's a bad thing necessarily, but if one of the benefits of microservices is loose coupling, it's not going to encourage a good microservice architecture.