What microservices allow is for different teams to use different technologies and to upgrade components independently. On service might by Python+postgresql, another Ruby, and third also Ruby but two versions ahead.
It feels fast and agile in the short-term to decouple teams like this. In the long-term, it's almost always a maintenance nightmare. You end up with way too many different technologies.
I usually break up my projects into libraries (in Python, independent pip-installable packages) with their own unit tests, and some pretty weak glue in the middle. The service layer is omitted. I design things to scale horizontally too.
I've built apps with a few services, but I've never seen a good example of a microservice architecture that beat good old-fashioned clean abstractions in libraries.
Every few years, someone comes up with a new way to do abstraction, and compares that to no abstraction (rather than good abstraction with the previous model. Microservices seems like the dumbest of the bunch I've run across in my career.
From a high-level perspective, is there really any difference between DMI and HTTP/gRPC/et.al. if you could hypothetically run all of your services on a single logical node? If your entire production stack runs on your macbook, why cant you just wire it all up as a single binary and throw it on a nice powerful server? I guarantee it will run better without all that ridiculous network glue in the middle.
If I am being modest, I would say that we feel really, really stupid from where we are sitting right now. Primarily for having previously spread this implementation across 10+ services talking HTTP for absolutely no good reason. I am growing into a mindset where the entire business system needs to fit into 1 binary image. Perhaps duplicated across more than 1 physical host with differing features enabled per, but at least sourced from the same solution/repository.