It didn't come as a total surprise that Microsoft was going to stop its support for Service Bus for Windows Server. But now we're left in a void when it comes to on-premises queueing. Where MSMQ isn't really an alternative, RabbitMQ does seem to be. It might even have always been the better alternative for on-premises queuing anyway. This talk is meant to get people introduced to RabbitMQ and its capabilities. What is RabbitMQ, how does it work, and how is it different from Service Bus for Windows Server? Those are just a couple of questions I'll try to answer during this session.

1. Down the RabbitMQ hole
Life After Service Bus for Windows Server

2. Why?
https://days.to/until/9-january

3. Alternatives
 Apache Kafka
 RabbitMQ
 Apache Active MQ
 Kestrel
 Redis ?
 MSMQ

4. Kafka
Global Apache Kafka architecture (with 1 topic, 1 partition, replication factor 4).
Source: http://kth.diva-portal.org/smash/get/diva2:813137/FULLTEXT01.pdf

5. Kafka
 Stream from A to B without complex routing, with maximal throughput
(100k/sec+), delivered in partitioned order at least once.
 When your application needs access to stream history, delivered in
partitioned order at least once. Kafka is a durable message store and clients
can get a “replay” of the event stream on demand, as opposed to more
traditional message brokers where once a message has been delivered, it is
removed from the queue.
 When you have smart clients who can reliably track their log offset.
 If your application needs an “infinite” queue.

6. RabbitMQ
Simplified overall RabbitMQ architecture. Source: http://kth.diva-
portal.org/smash/get/diva2:813137/FULLTEXT01.pdf

7. RabbitMQ
 Your application needs to work with any combination of existing protocols like
AMQP 0-9-1, STOMP, MQTT, AMQP 1.0.
 You need mature, well understood consistency guarantees for your message
delivery.
 Your application needs variety in point to point, request / reply, and
publish/subscribe messaging.
 Complex routing to consumers, integrate multiple services/apps with non-
trivial routing logic.
 When integration with your existing IT infrastructure is important, RabbitMQ
shines.
 Use 3rd Party Apache Cassandra for stream history.
 Use 3rd Party LevelDB plugin for an “infinite” queue.

8. RabbitMQ

9. Pros
 It’s AMQP, just like Service Bus Messaging.
 It’s widely accepted, it’s probably the most used queuing solution on-prem at the
moment.
 It’s mature, it is currently celebrating it’s 10th anniversary.
 It’s stand-alone and doesn’t use SQL server (or any other commercial
database). Why do I also have to pay for SQL Server for something like queuing?
 High availability only requires 2 machines, whereas Service Bus for Windows
Server requires at least 3 machines in its farm && a SQL cluster.
 It’s cross-platform: Windows, Linux (multiple distributions) and Mac.

10. Pros
 It supports all popular programming platforms and languages. This is really
neat. No more Mono stuff needed, just use Java or PHP.
 Python, Java, Ruby, PHP, C#, JavaScript, Go, Elixir, Objective-C, Swift
 It supports multiple messaging protocols
 AMQP 0.8 - 1.0, STOMP (text based), MQTT (IoT) and messaging over HTTP (API,
AMQP over JSON-RPC)
 It has a built-in management portal to manage about everything. Includes
stats.
 And last but not least, the comprehensive documentation!
 Ow… and MSMQ is not an alternative, better go wash your mouth.

11. Cons
 There’s no adapter in BizTalk (so we programmed a WCF binding in a few days
time probably).
 You’ll need to get used to the “Rabbit-way-of-working”, but you are never too
old to learn.

12. Support and Cloud
 Commercial (supported) version:
 Pivotal RabbitMQ is the go-to commercial version
 https://network.pivotal.io/products/pivotal-rabbitmq
 Cloud versions:
 CloudAMQP (out-of-the-box, AWS, Azure, GCP)
 Microsoft Azure (Bitnami)
 Amazon Web Services
 Google Cloud Platform

13. Patterns
 Direct
 Fanout
 Topic
 Headers

14. Direct
 Routing is based on the routing key sent along
 The routing key defined in the direct exchange should exactly match the
routing key sent along

15. Fanout
 Binding is done on the exchange
 Any info, like routing keys or headers, are discarded. The message will always
be sent to all bound queues.

16. Topic
 Works with wildcards

17. Headers
 Routing is based on headers sent along with the message
 Equivalent to e.g. SOAP Headers or even BizTalk Context

18. RPC Call
 Request on one queue
 Response on another
 Acknowledge after sending the response

19. Life After Service Bus for Windows
Server?
I’d go for RabbitMQ
 It’s light-weight
 It’s reliable
 It’s easy to use, comprehensive documentation
 It supports AMQP
 It supports all major programming languages: Java, .Net, PHP, etc
 It supports all major platforms (server): Windows, Linux & Mac

20. Sources
 https://www.rabbitmq.com
 https://content.pivotal.io/blog/understanding-when-to-use-rabbitmq-
or-apache-kafka
 https://content.pivotal.io/blog/messaging-patterns-for-event-driven-
microservices
 https://engineering.linkedin.com/distributed-systems/log-what-every-
software-engineer-should-know-about-real-time-datas-unifying
 https://dzone.com/articles/exploring-message-brokers