[brhsagain]

> Splitting a system into subsystems allows each team to focus on their piece of the puzzle while minimizing the amount of peer-to-peer coordination.

This does not happen at all. When you break a system into subsystems, all the previous connections that get remapped to new connections between subsystems still need to happen, in order to solve the fundamental problem that the system solves — except now instead of just making the connection directly, there has to be a "cross-functional" meeting between teams and a complicated communication layer between the systems. And if somehow you find a breakdown that requires minimal connections between subsystems, then those connections wouldn't have existed in the original system either, and the N² problem doesn't exist.

[devoutsalsa]

It's all fun & games until product wants to add a feature that doesn't map cleanly to your micro servies architecture. Then you end up hard coding you services into a macrolith. Good times.

[jedberg]

If that's the experience then you're doing services wrong. Each service should have its own datastore and a single API. The interface between services should be a single connection.

There should be maybe one meeting where the caller defines what they need the service to return to them.

[10000truths]

The problem with this is that you have to be really damned careful how you split things up. If your separate data stores end up having to be joined together later on because some new business feature requires them to be cross-referenced, you're painted into one of two corners:

1. Merge the two services (and their data stores) into one and cause havoc downstream of either service

2. Burn through your network latency/throughput budget trying to reinvent a DB join across RPC boundaries (and god forbid if you can't batch multiple lookups in a single API call!)

[dahwolf]

Exactly. Software developers will never learn that the separation of concerns is a myth. In reality, UI, business logic and data are deeply entangled. Hence, moving these things apart makes everything worse.

[ris58h]

> There should be maybe one meeting

Oh sweet summer child

[jedberg]

I do not like appeal to authority either. But based on my experience, most of these issues were resolved in one to two meetings (I said maybe one, after all).

The team that needs data goes to the team that has that data and says "can you make an API that vends the data that I need?". Then they make it. And then maybe there is another meeting with a follow up, or perhaps an email asking for the data to be presented slightly differently.

But if you come to a team with a good use case and some examples, it shouldn't be too hard for them to create an API that vends the data appropriately.

This of course is all predicated on a good microservices architecture where you already have systems in place to handle API discovery and communication between services and proper data separation.

[sethammons]

I'm willing to bet you do not know who you replied to. Their resume is more impressive than most.

[ris58h]

https://en.wikipedia.org/wiki/Argument_from_authority

[RugnirViking]

your "argument" was literally just telling the person that they were naive for thinking things could ever be handled by one meeting.

turns out, they inarguably have a whole lot of experience at high levels in the biggest companies in the world. Either they're straight up lying, or it is in fact possible to resolve things with a single meeting. Why wouldn't that be the case?

[ris58h]

I can tell you many other wisdoms: code should be tested, code shouldn't contain bugs, everything should be done before deadline, etc.

The thing is in reality it's not that easy.

> Either they're straight up lying, or it is in fact possible to resolve things with a single meeting.

Something can be done in a single meeting but not everything. But you gave me only two alternatives without anything between so there is another useful link for you https://en.m.wikipedia.org/wiki/False_dilemma

[threeseed]

> there has to be a "cross-functional" meeting between teams and a complicated communication layer between the systems

Of all the things wrong with micro-services this isn't one of them.

The "complicated" communication layer is always either REST/JSON or GRPC.

Both of which are simple, easy to debug, proven and require nothing more than a simple discussion over an API contract.

[The_Colonel]

> Of all the things wrong with micro-services this isn't one of them.

It is, exacerbated by the over-use.

> The "complicated" communication layer is always either REST/JSON or GRPC.

Going over network, which is slower, unreliable, poorly typed. It's orders of magnitude more difficult to refactor a published REST API in comparison to e.g. Java interface within a monolith.

Microservices are generally far from easy to debug. In the best case scenario you have the whole stack locally and can put breakpoints, add logging immediately. But that happens rarely, debug port is often blocked (security), you can't easily modify the code to add some diagnostics without a complex CI dance etc.

[threeseed]

Maybe you've only worked on small projects.

But I've never worked on a monolith project that I could run entirely locally.

And this idea that APIs are slow, unreliable and unable be to be strongly typed is nonsense. This is 2023. We have plenty of tooling and techniques to make this robust.

[The_Colonel]

The (monolith) product I currently work on has about 200 engineers working on it (backend + frontend + devops). I'd say it's of medium size, certainly not small. And yes, we can run it locally easily. The monolith starts up in like 20 seconds which I consider quite acceptable.

There are few narrowly defined responsibilities which are handled by dedicated services, and it is often more awkward to get them working locally. But because they are so specialized, you need them only rarely.

> And this idea that APIs are slow, unreliable and unable be to be strongly typed is nonsense.

Network APIs are inherently slower and more unreliable in comparison to an in-process method call. Some typing solutions are there, but they are way more awkward (and in some ways weaker) than statically typed monolith interfaces.

[plugin-baby]

> I've never worked on a monolith project that I could run entirely locally.

What are some examples of monolith components that couldn’t be run locally?

Im guessing third-party integrations, but perhaps there are other things.

[threeseed]

For a monolith it's having to run the entire platform locally to fix one bug.

That includes databases, caching, auth, ML models, mock API endpoints etc all pre-populated with sample data then the actual application which for complex, JVM based ones can often fail to launch if there isn't enough memory to pre-allocate.

Many systems I have worked on all of that would simply not fit on a 16GB MBP.

[deterministic]

I work on very large monoliths all the time. The kind of code that runs international airlines and airports. I run it locally in a VM. No problem.