One of the goals of Istio is to move the machinery out of the app. While a message queue/broker such as RabbitMQ or NATS is brilliant at distributing requests, you do have to build the glue — both the client and the server — into every single app, in every single language. You also need to write the edge proxy that mediates between HTTP and whatever the message queue/broker solution uses.

Istio (or rather, Envoy) acts as a plain HTTP proxy, meaning a client can just respect the standard http_proxy environment variable (which most client libraries do), meaning a client can just do HTTP and doesn't even need to know about the proxy. Even "curl" will work with Istio. And it's even simpler on the server end; all a server needs to do work is to accept HTTP connections.

Last I heard, Istio aims to go even further by supporting the proxying of any networking protocol (Layer 4).

I architected and built a system based on MQ a number of years ago. The very same design / implementation went from supporting 0 messages to a billion messages a day quietly and silently with full message tracing, retries, multi language support, etc.

Maybe I should have blogged about it :)

Anyway, although all the design principles are the same: 1) Transparent and seamless to application code, 2) Control communication end points, the MQ constructs and languages are not as accessible and readily available and visible as HTTP and RESTful.

A MQ can be temperamental and hard to operate. On the other hand, even middle-schoolers can master nginx, haproxy, write their own, etc with a bit of guidance :)

Popularity and rate of adoption depends on availability to the masses and the ease with which the masses can learn to use. If it takes to long (say, 15 minutes) to bring a framework up, hordes of engineers will find a massive number of reasons to roll their own ...

Just for your benefit, we've moved from AMQP related products to nats.io. We've been satisfied with RabbitMQ and are extremely happy with nats.

MQ shines in async calls/event delivery. gRPC / http2 / websockets / thrift is better for synchronous calls ?

With the ISO/oasis standard AMQP you can actually do synchronous calls without an intermediary. You also have 'direct' message routing capability with components like apache qpid dispatch router.

I can't see a reason why one would use gRPC/thrift and then having to build flow control, delivery guarantees and other messaging features yourself.

gRPC is built on http/2. I imagine it supports flow control and delivery guarantees already? It's just http/2 + protobuf

See GRPC for a common alternative to HTTP. Kafka and Kinesis are common event buses.

But message queues are usually an added complexity for realtime inter-service messaging.