I don't think it's necessarily an either/or. Some services will do better with HTTP/gRPC and others with messaging. It's about picking the right tool for the job.
Even between HTTP and gRPC it isn't one size fits all. For our high throughput part of our application we'll use gRPC due to the decreased overhead. But HTTP is easier to read and debug, so that would be the default choice for our other direct-call scenarios.
And some services benefit from messaging but there is also additional complexity there. Does your system behave if the message is delivered twice? If the messaging service is a deliver once queue, what happens when the service dies after getting the message?
You really have to think about which services benefit from which communication method and what the tradeoffs are. Obviously HTTP/gRPC suffer from some of their own pitfalls.
Unless your app is very simple, in which case microservices probably are more of a hindrance, you will likely need both.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.