9

Help me to understand something. I've looked at several enterprise application architectures, and I've noticed that several of them use a Message Queue service, like ActiveMQ or RabbitMQ. I have surface-level knowledge of what message queuing servers do, but I don't really understand why I would choose to build an application infrastructure that uses one, versus a standard load balancing technology, like HAProxy, or the like.

What is the real difference between the two? Both seem to route traffic and/or messages to nodes that subscribe to the queue or pool. Are there pros/cons for each of these?

Jason Clark
  • 125
  • 1
  • 4
  • 5
    These really have nothing to do with each other. – Michael Hampton Jul 18 '13 at 20:36
  • 2
    OK, so what's the difference? What do I get with an MQ service, and what is it about an MQ service that cannot be achieved with a load balancer? – Jason Clark Jul 18 '13 at 20:37
  • 7
    Don't take this the wrong way, but if you don't understand the difference between the two technologies or where you would apply them you're not really in a position to be evaluating either as a solution. If you're trying to decide which to use based on what they do you're approaching the engineering problem backwards - The question you should be asking is **I need my environment to do `X`, what technology enables that?**, not **I have a technology that does `Y`, where/how can I use it in my environment?** – voretaq7 Jul 18 '13 at 20:45
  • 6
    If I would like to build a house one day, I'd like to know what the difference is between a hammer and a paintbrush, and when I should use each. I'm not building a house right now, I'd just like to know when I should use each tool. That doesn't sound like an unreasonable question to me. It's like you're saying don't build houses until you know what a hammer and paintbrush is, and don't ask people who build houses. – Jason Clark Jul 18 '13 at 20:52
  • 2
    @JasonClark - this site is for professionals and we have a reasonable expectation that said professionals will do their due diligence in researching things before asking here. – EEAA Jul 18 '13 at 20:55
  • @JasonClark That sounds about right. Would you _really_ walk up to a construction site and ask what the difference between a hammer and a paintbrush is? – rtf Jul 18 '13 at 20:57
  • @r.tanner.f Yes. The same way I ask my instructors questions as a student in class. If I wasn't clear, and I wanted to know, yes. And I would do it without the fear of being ridiculed for doing so. – Jason Clark Jul 18 '13 at 21:02
  • 1
    Actually, I'm fairly sure that walking up to a construction site and demanding that people there stop their work to explain the difference between a hammer and a paintbrush to a random bystander who doesn't even have the sense to read up on building before asking, is quite likely to be met by ridicule... – Jenny D Jul 19 '13 at 09:46
  • @JennyD though the one construction worker who sees an eager young student who wants to learn about building houses is appreciated when he stops his work to do so. Thanks EEAA. – Jason Clark Jul 22 '13 at 13:39
  • 1
    The question was more about what the benefits message queuing are, and how to recognize when and where to use message queuing. I have a good understanding of load balancing, and how that benefits HA applications. What I was unclear about was the distinct benefits that MQ servers provide. I think EEAA has answered that question now. No need to continue the trolling over house building. – Jason Clark Jul 22 '13 at 13:45
  • 1
    This was very poorly handled and @JasonClark was abused. I'd like to apologize to him on behalf of a community of engineers who all owe an unpayable debt to those who came before us and have generously shared their knowledge with us. There is no expectation that people asking questions be experts in the domain they are questioning, only that people answering be experts. He didn't walk onto a jobsite and demand people stop working. Aggressive passers-by saw an opportunity to abuse someone they perceive as inferior and the took it because it brings them pleasure. – Bruno Bronosky Dec 14 '16 at 04:55

1 Answers1

16

As stated by Michael, these two are vastly different in function and capability.

Message Queuing Systems

The primary function of Message Queueing services is to permit asynchronous communication between different parts of an application. MQ servers typically allow one to configure an arbitrary number of routing rules, queues, etc. to which messages are published by parts of an application and subscribed to by other parts of the application.

Take, for instance, a video transcoding application. The basic functions needed are:

  1. user uploads a video file
  2. system transcodes video into a different format
  3. system makes transcoded video available for download

After step 1 completes, do you really want the user's browser session to hang for 45 minutes while the transcoding takes place? Nope, don't think so. So instead of performing the transcoding synchronously, you dump a message into a message queue that there is work to do. Then this message is picked up by the back-end processing part of your app, which performs the transcoding and then when complete, publishes an "I'm done!" message to a different queue, which triggers a third part of your application to email the user that their job is complete.

In addition to separating disparate parts of your application, MQ systems permit jobs to, well, queue. Say your hardware only allows you to process one video every 30 minutes, but during peak load, your users upload more than that. Using an MQ allows those jobs to queue up gracefully and be handled in sequence as the back-end is able to do so.

Load Balancing Systems

The primary function of load balancing is to field incoming requests from clients and distribute those requests one or more back-end application servers.

Conclusion

To put things another way, message queuing services focus on asynchronous communication between disparate application parts, while load balancing services focus on synchronous communication between clients and one or more of a pool of back-end servers.

EEAA
  • 108,414
  • 18
  • 172
  • 242
  • OK, cool. Although I understand your explanation, I still can't clearly determine when to use a MQ server. Load balancing is clear to me. I get that. But, what do I have the ability to do with an MQ server as opposed to building an application architecture that doesn't use one? Is it the asynch communication between servers, and the FIFO messaging functions of MQ that benefit me in some way? – Jason Clark Jul 18 '13 at 20:57
  • 1
    @JasonClark - I think the use case outlined in my answer makes that clear. – EEAA Jul 18 '13 at 20:58
  • thanks that makes ALOT of sense now, thank you. very clear example and explanation. – Jason Clark Jul 18 '13 at 21:06
  • @JasonClark - the **vast** majority of applications need some sort of message queuing. So you're either going to end up building queuing mechanisms yourself or you can use a pre-built system like Redis or RabbitMQ. – EEAA Jul 18 '13 at 21:07
  • so the difference is just about synchronous and asynchronous??? – Obaid Maroof Dec 15 '15 at 18:07
  • @JasonClark [a]synchronous is a big concept not always as extreme as transcoding video. Think of MQ as a way to reduce the number of servers you need behind your LB. If your web server can handle 100 concurrent requests and you use an external API that takes 5 seconds to respond, you can only handle 20 requests/second (per server). If sending that API call to an MQ and collecting the result later via AJAX lets you complete the request in .25 seconds, you can handle 400 requests per second. You'd need 20 web servers behind your LB to satisfy that the original way. – Bruno Bronosky Dec 14 '16 at 05:12