[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.