Monolith First (2015)

Yup. You ship your org structure.

I think microservices can be useful for nontechnical reasons: They let you take the "org chart becomes architecture" from an unseen, not really understood force into something explicit that you can observe and manage.

Instead of multiple teams working on the same codebase and stepping on each other's toes, each team can have clear ownership of "their" services. It also forces the teams to think about API boundaries and API design, simply because no other way of interaction is available. It also incentivices to build services as mostly independent applications (simply because accessing more services becomes harder to develop and test) - which in turn makes your service easier to develop against and test in (relative) isolation.

However, what's of course a bit ridiculous is to require HTTP and network boundaries for this stuff. In principle, you should get the same benefits with a well-designed "modulith" where the individual modules only communicate through well-defined APIs. But this doesn't seem to have caught on as much as microservices have. My suspicion is that network boundaries as APIs provide two things that simple class or interface definitions don't: First, stronger decoupling: Microservices live in completely separated worlds, so teams can't step on each other's toes with dependency conflicts, threading, resource usage, etc. There is a lot of stuff that would be part if the API boundary in a "modulith" that you wouldn't realize is, until it starts to bite you. Second, with monoliths, there is some temptation to violate API boundaries if it let's you get the job done quickly, at the expense of causing headaches later: Just reuse a private until method from another module, write into a database table, etc. With network/process boundaries, this is not possible in the first place.

It's a whole bunch of very stupid reasons, but as they say, if it's stupid and works, it ain't stupid.

I understand what it means, I'd like to know where the monolith architecture stands in this context. One of our projects was originally a monolith, and each tenant had their own dedicated DB the monolith connected to. Then they switched to the microservice architecture (back when it was the peak of the hype) and rejected the idea of database sharding because each microservice already requires their own DB, and if you also sharded by tenant, then you'd end up with M x N databases (where M is the number of tenants and N is the number of microservices) which sounds like a lot of complexity to manage. I think they once had a bug where one tenant could see data from another tenant because they don't have strong DB boundaries anymore.

Is there a large enterprise that exists in 2024 that doesn't already have existing software?

> Scaling a monolith is almost always cheaper than migrating to microservices and scaling that.

No - it depends on capacity needs and current architecture.

> When you split it into microservices you are adding a bunch of infrastructure that did not need to exist.

Unless you need to scale in an economical manner.

> Your app performance will likely go way down since things that used to be function calls are now slow network API calls.

Not necessarily. Caching and shared storage are real strategies.

> Add to that container orchestration and all sorts of CNCF-approved things and the whole thing balloons.

k8s is __not__ required for microservice architectures.

> If you deploy this thing in a cloud, just networking costs alone will eat far more than your $20

Again, not necessarily. All major cloud providers have tools to mitigate this.

To clarify: I'm not a microservice fanboy, but so many here like to throw around blanket statements with baked in assumptions that are simply not true. Sometimes monos are the right way to go. Sometimes micros are the right way to go. As always, the real answer is "it depends".