...no, not at all. There are a couple of operational benefits, but vastly more drawbacks, and on balance microservices are phenomenally harder to operate than monoliths.
Organizations adopt microservices when the logistical overhead of coordinating teams against a monolith becomes so large that it starts affecting product velocity. Microservices are a way to release that organizational/logistical friction, at great technical cost.
With that said, the domain-oriented bounded context is indeed the right way to think about service delineation.
We went microservices for the canonical reason you should - to be able to release and scale independently.
We were used by health care networks. Can you imagine the increased use post-Covid?
We even had some that were both hosted on Fargate (Serverless Docker) with lower latency, more expensive but slower scaling for online use and hosted on Lambda for internal batch use - higher latency, faster scaling, less expensive for batch use. The CI/CD pipeline deployed to both.
That instead of being able to granular take part of the application that had a larger load, and run it on a Firecracker micro VM (the underlying VM for lambda and Fargate) with 256MB RAM and 1 core, we add enough VMs to scale a monolithic app - even the parts that don’t need it on a full scale VM with 8GB RAM and four cores?
We did actually have to do something similar for a legacy Windows app. We scaled the entire process up based on the number of messages in the queue. It was extremely wasteful. It required at least a 4GB/2 CPU VM compared.
edit: If breaking out one service from your monolith worked for your use case, that's great. I'm not trying to deny your experience. It is atypical, however.
because a read replica actually is the same database application (same "monolith") just started with different parameters, to behave as a replica
It’s not just a matter of spinning up a database.
Also, since many enterprise apps live stores procedures and putting business logic in the database, that’s another ball of wax you have to untangle.
That's certainly one of the operational limits, but arguably not the most important one.
You distribute your system so that parts of it may scale independently, for example. Traffic fluctuates along time and the only option you have to scale your system is adding nodes as you go.
Microservices are a solution to organizational problems, not technical problems. On balance they create far more technical issues than they solve.