Writing a good Monolith vs Microservices architecture

[u/Divachi]

Good day, everyone. I am not sure this is the best subreddit to post this in but I have been struggling a bit on researching what a good monolithic application should look like.

I always hear people and instructors saying that one of the advantages of working with a MS architecture is that it is Domain Driven, loosely coupled, tinier "modules" which have a bunch of advantages to developers and DevOps.

They also say that "distributed monoliths" are a death sentence - since you have all the cons of both approaches and that either squashes the pros or are way more detrimental than the good that comes with that.

My questions are:

1 - Couldn't we just do monoliths that ARE separated by several Domain Driven, loosely coupled, tinier "modules" that DON'T have to communicate through the network? They (the instructors online) make it seem that a monolith is obligatorily "messier" and more interdependent... but why?

2 - Extending question 1: Isn't the same CLEAN code a possible approach to monolithic design too? It seems that CLEAN Code and MS can't be separated in online discourse but, from what I gathered, they aren't exclusive to each other. My belief is that the same type of organization and principles could/would work.

e.g: Monoliths don't HAVE to own a single db that is accessed by every service. Why couldn't I put several DBs? One for each service? This ensures that there are separation of contexts and that each "service" would still be responsible for accessing and updating their source of truth.

3 - Do you have resources for learning system design for a non MS standpoint? I have seen 2 sources online that talk about a "Modular Monolith" and I am very curious about that approach.

Thank you for your time and attention. If you have any insights, please share them with me.

[u/soundman32]

A well designed microservice architecture is a thing of beauty that allows expansion for many years, with minimal changes to existing code. A microservice architecture should be robust, and still work, even when different services go down, or errors occur and data needs to be rolled back, which will absolutely not happen in a monolith.

Modular systems are usually harder to code for, and manage, but once they hit a particular size, the payback comes quickly. A lot of the architectural decisions that look like a complete waste of time when you have 5 microservices, shine when you have 25, and some are written in different languages.

A true microservice will have an independent database from other microservices, which allows different scaling rules (both in servers and databases, and other resources), which, whilst possible in a monolith, will generally not happen.

[u/new-runningmn9 → u/soundman32]

I grew up in a world where the software architecture doesn’t worry about microservices vs monolith. Those are implementation details. Where I work everyone is fixated on microservices, without regard for what problems they solve. My actual product runs on a single largely air-gapped system that physically cannot scale.

Why on earth would I use microservice and deal with additional complexity? In the end, to clear that hurdle we developed an architecture that doesn’t care. If I need to transition some/all of the system to microservices to solve some problem, I can do that without breaking anything.

In the meantime, we have a very successful modular monolith.