Making the MQ versus RPC decision
Among many software architects and pundits, Message Queue solutions have a lot of press about being a highly scaleable solution in comparison with RPC based solutions. From what I can see, the biggest problem with most comparisons is that they start with the premise that one or the other of these two approaches is superior and then spend time trying to make a compelling argument why they are correct.
I'm going to throw my hat in the ring on this issue and offer a high level guide for folks who don't have the time or energy to dig into queuing theory or debate with ivory tower architects about the issue. You'll note that scaleability is not even a factor. This is deliberate as scaleable and performant solutions can be built using either pattern. There is an interesting performance comparison that seems to indicate that the performance characteristics are very similar for both approaches. I WILL point out that simple http-based RPC solutions DO have fewer middleware requirements and are almost universally accessible. Furthermore, I'll point out that it is entirely possible that a real world solution may need both.
In any event, some strong indicators you'll likely need an MQ based solution include:
From my perspective, if any of these are necessary, then some sort of MQ technology is probably appropriate. Certainly, if you try to build a custom solution to either of those problems, you're highly likely to be wasting your time.
On the other hand, some equally strong indicators that an RPC solution is probably your best choice:
The first bullet is most important above, synchronous message queuing patterns (e.g. request/response) typically come with a lot of baggage that may be hurting both your performance AND your scaleability.
I've worked with a variety of solutions using MQ series, JMS providers, and Biztalk, used both appropriately and otherwise. In every case I can remember, if we had used the above guide, we would have had a better chance of picking a the most appropriate solution and also arrived at the conclusion more quickly.
I'm going to throw my hat in the ring on this issue and offer a high level guide for folks who don't have the time or energy to dig into queuing theory or debate with ivory tower architects about the issue. You'll note that scaleability is not even a factor. This is deliberate as scaleable and performant solutions can be built using either pattern. There is an interesting performance comparison that seems to indicate that the performance characteristics are very similar for both approaches. I WILL point out that simple http-based RPC solutions DO have fewer middleware requirements and are almost universally accessible. Furthermore, I'll point out that it is entirely possible that a real world solution may need both.
In any event, some strong indicators you'll likely need an MQ based solution include:
- I need multiple endpoints to subscribe to my message
- I need durable messages that can be delivered even when the message destination is not running
From my perspective, if any of these are necessary, then some sort of MQ technology is probably appropriate. Certainly, if you try to build a custom solution to either of those problems, you're highly likely to be wasting your time.
On the other hand, some equally strong indicators that an RPC solution is probably your best choice:
- I need clients to get an answer immediately
- I need a very small footprint and performance and simplicity are more important than reliability
The first bullet is most important above, synchronous message queuing patterns (e.g. request/response) typically come with a lot of baggage that may be hurting both your performance AND your scaleability.
I've worked with a variety of solutions using MQ series, JMS providers, and Biztalk, used both appropriately and otherwise. In every case I can remember, if we had used the above guide, we would have had a better chance of picking a the most appropriate solution and also arrived at the conclusion more quickly.
Comments