[karmakaze]

I've been there. This only seems to 'work'--until you try to raise throughput/reliability and lower errors/latency. What ends up happening is that the module boundaries that made sense in a monolith don't make sense as microservices when communications are allowed to fail. Typically the modules are the source-of-truth for some concern with consumers layered above it. This is the worst pattern with microservices where a synchronous request has to go through several layers to a bottom-level service. With microservices you want to serve requests from self-contained slices of information that are updated asynchronously. The boundaries are then not central models but rather one part of a workflow.

[diveanon]

Or you can do poor man's microservices and use the same monolith with different production flags to load balance it.

Keep all your code in one repo, deploy that codebase to multiple servers, but have it acting in different capacities.

1 email server, 5 app servers dishing out html, 2 api servers

Etc

It works very well and was able to handle spikes of traffic during super bowl ads without any problems.

[bitterchicken]

This is the biggest favor you can do for yourself. The developer experience is as easy as production without descending into container induced madness.

[diveanon]

Testing is a breeze too because you are using the same tools across the board.

I don't know why it fell out of fashion, but for your average web app it is the gold standard imo.