So what is Service Bus?
A Service Bus is essentially a message queue, a little like a webservice but without any processing. It simply receives JSON/XML messages from one component and relays them on subscribers.
Why is Service Bus Useful?
- Its reliable – Service bus (at least the good ones) guarantee the delivery of messages. Azure service bus has At-Least-Once and At-Most-Once delivery. This means that when you send a message it is first stored locally then sent to the service bus. It is guaranteed to get to the queue once and only once even if your network goes down, your laptop runs out of battery or someone unplugs your server.
- It decouples components – When you implement a service bus both the producer and stop talking to each other and just talk to the bus. Loosely coupled components are easier to change and more robust, how can something you don’t know about going down affect you after all?
- It makes adding consumers easy – Since the component producing messages is decoupled from the consumers you can add consumers with zero work and zero configuration to the producer. Simply set up a topic broadcasting messages when events happen. Any consumers that cares about those events can then subscribe and get a copy each of that information. If you build a new component that needs that information too then you just need to subscribe them to the topic as well, no extra work for the producer.
- It allows easy multi platform integration – So you have a chat server in node, a website in .Net and some legacy back end process written in Java. Without service bus this would be a nightmare to tie together and maintain. Implementing service bus will allow these components to nativity consume the information from the bus and play nicely together. Azure Service Bus currently has an SDK in .Net Node, PHP, Java and Python as well as a REST Api. Several other Service Bus implimentations have an even wider array of support (ie http://www.rabbitmq.com/devtools.html)
- It makes redundancy a piece of cake – Its a fact of life that Servers fail and occasionally need to be taken down for upgrades, maintenance and the like. In coupled applications if one component goes down it becomes very hard for other components to keep working correctly. There are several complex solutions out there to ensure redundancy but one of the simplest and best solutions is Service Bus. You simply set two or more servers to pull messages off the same queue. The service bus itself then ensures the messages are delivered to just one consumer. If one consumer goes down everything continues to work as normal, although messages are processed slower as only one consumer is pulling messages off. When everything is fixed the consumer just comes back on line and everything caries on as normal.
- It flattens load – Any processing done by downstream consumers is all queued. It means that big spikes in load wont affect anything, the work will simply be queued up and dealt with as normal.
Why is it so essential for Azure?
What cloud services like Azure do really well is scaling out, having lots of small components rather than single large ones. It costs no more to have four small instances than one large one and in most cases four smaller servers can get a lot more done. This is especially true when you are using service bus since you don’t need to worry about load spikes for downstream consumers and you can keep load on each box high. Service bus is a great way of minimising your Azure expenditure and squeezing the most out of your CPU cycles.
How can I find out more?
Cloudcast has a great introductory guide to service bus and the underlying concepts. Its concise and very well written.
As usual MSDN has a wealth of information with some nice code examples.
You can also get the SDK and have a play.