A Queue By Another Name


Published on

When Windows Azure was originally released a built in queuing feature was included. The Windows Azure Storage Queues were the suggested way for compute instances and applications to talk to each other. Flash forward to just a few months ago and another queue feature appears on the Windows Azure scene with Service Bus Queues and Topics. So, why are there two queue technologies? How do they differ? When should you choose one over the other? These are the questions we'll look to answer in this session.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • ExpectationsThis is NOT going to be an intro to Cloud Computing, or even the concept of queues. I will be contrasting two technologies that are available on the Windows Azure stack that both offer queuing capabilities. I will be happy to answer questions about them as we move forward, but I reserve the right to tell you to see me after the session or contact me through my blog. My goal today is to arm you with the information you need to make good decisions on which technology you need, not to dictate which one you should use.What images come to your mind when I say queue?Images:Xbox Live Avatar - MicrosoftComic: http://www.xkcdefg.com/?id=23 – XKCDEFG – Used under Creative Commons Attribution, Non Commercial license
  • If you’re from England a queue is a line. The line could be for just about anything. Concert tickets, good food…Image: Donald McCleod – Used under Creative Commons, Non Commercial License - http://www.flickr.com/photos/donaldmacleod/5457669121/in/photostream/
  • Or perhaps something more important (or at least likely urgent).Image:ShellS – Used under Creative Commons, Non-commercial, Share Alike license - http://www.flickr.com/photos/shellysblogger/2119822362/in/photostream/
  • What are we talking about today?But for today we are going to concentrate on computer based queues. A way to store messages that come into our system for processing that is disconnected from those sending us those messages.Specifically we are going to talk about Windows Azure Queuing technologies. I say technologies, because there are two different options for you: Windows Azure Storage Queues and Windows Azure Service Bus Queues. We’ll talk a little about each option, then delve into why there are two of them, and finally we’ll walk through their differences. From time to time I’ll break out into a demo just so that you aren’t bored out of your minds.
  • When it was the only one.Offload workDirect communication issues.When Windows Azure came out several years ago now we had the Windows Azure Storage Queues. Back then people just called them Azure Queues because it was the only option in the cloud. Their main purpose in life was to help decouple direct communication between machines running within an Azure application. One or more producers could write to a queue and one or more receivers could pull them to do work. It also reduced the need for machines that had transient lifetimes to be overly aware of specific machines they needed to talk to. This type of decoupling helps make systems highly scalable and highly available. Beyond just instance communications queues are designed to offload long running work to other systems, freeing up other resources. For example, web sites submitting long running operations to a queue and returning to the user so that the web site can scale well and give a good user experience.
  • Demo the Windows Azure Storage Queue.Simple creating a queue, adding to it and getting a message out.I left out how to create a Windows Azure subscription, as well as how to create a storage account. If you want to learn more about those check out:Windows Azure Subscription: http://www.windowsazure.com/en-us/pricing/free-trial/ Windows Azure Storage Account: http://msdn.microsoft.com/en-us/library/windowsazure/gg433066.aspx
  • Let’s talk just a bit about idempotence. The term idempotent is an indication that no matter how many times an operation occurs it has the same outcome. Think about the scenario where you process an image file into a thumbnail. You pick up the file, you resize it in memory and you save it. As long as the same filename/location is used each time you save the thumbnail you can run that as many times as you want, and you only have a single thumbnail. Or think to my demo where I used an idempotent snippet of code to create my queue. No matter how many times I ran that code, there would still only be one queue.Now let’s think a bit about what happens if a message is being processed and something happens that causes the message to not be complete (either within the timeframe allotted in the lease, or if a machine has a hardware failure).As messages come into the system they are queued up. Consumers on the other side are pulling from the queue. If one of them has a failure or the process time goes over the allotted lease time then the message will become visible again on the queue and another machine may pick it up. This is called “At least once delivery”. It means that unless you plan for this situation your code could process a message multiple times. This is where you need to think about making your processing idempotent, or calculating a way to deal with duplicate messages (either by shunting them off to a human for review or by having compensating transaction to roll what you have done back, or know where to pick up where the other left off).Windows Azure Storage Queues have “at least once delivery”, and that’s your only option so your design will definitely have to take that into consideration.
  • Then comes the SB QueuesWait? Wasn’t Service Bus ….In May of 2011 Microsoft released a CTP of Windows Azure Service Bus Queues (then referred to as Windows Azure AppFabric Service Bus Queues) and then released the bits for general availability later that year in September. The Service Bus Queues brought more functionality to the table (no, not Windows Azure Storage Tables) than the Storage Queues, but the two technologies differ enough that it’s not an overall one is better than the other in all cases.You might be thinking, hold on here, isn’t the Windows Azure Service Bus that technology that lets me register a service endpoint and then everyone can come hit that endpoint without the need for either me or my customers to punch holes in our firewalls? Well, yeah, that’s the original incarnation of the Service Bus and is now what they refer to as the Windows Azure Service Bus Relay. That still exists and is one of the reasons why a queuing mechanism grew out of the Service Bus stack. Image: John Ward– Used under Creative Commons, Non-commercial, Share Alike license - http://www.flickr.com/photos/25653307@N03/2783822822/in/photostream/
  • Let’s talk about what a traditional “Service Bus” is, outside the scope of the Microsoft version. Of course, you’re bound to get a lot of different answers to this definition, but according to the great tome of all knowledge (Wikipedia) the diagram above is a good representation of an Enterprise Service Bus. A Service Bus is really a decoupling mechanism so that various systems can raise or publish events and the events are then placed on the Service Bus. The Service Bus then routes the events to other systems that care about that event. The consumer either subscribe to the events on their own, or there is configuration to route the messages to the correct place in the integration layer. Now, the Windows Azure Service Bus Relay can be used to send messages, or even do direct tunneling, but it’s pretty much a relay only. Each consumer has to be aware of the service they are publishing to. In my opinion the Service Bus Relay is more like service endpoint hosting and registration and less like an actual bus. I’m sure someone might argue that with me, but that’s why it’s my opinion.Image: Axel Angeli – Used under Creative Commons Attribution 3.0 Unported license. http://en.wikipedia.org/wiki/File:ESB.png
  • Issues with Relay and communicationsNot durable/decoupled (no real routing out of the box)Here is the Service Bus Relay. I’ve simplified a great deal here, but a Receiver registers an endpoint on the Service Bus. Senders then connect to the Service Bus Relay and indicate they are pushing to the specific service the Receiver published. The Service Bus Relay then gets the two connected and the Receiver then receives the message or data from the Sender. This connection can be very transient, such as to send a message or perform a request/response operation, or it can be long lived to perform tunneling. One of the issues that the Service Bus Relay has is that the service must be up at all times. If the service fails then callers to the service will get an exception, their requests are not stored. There was a technology called Windows Azure Service Bus Buffers, but it wasn’t really durable and was designed to handle small downtimes of the service. They are keeping Buffers around for backwards compatibility, but they are deprecating it in favor of the service bus queues.As more producers came on the service could have a hard time scaling to meet the needs since only a single instance could initially register to listen. This became a single point of failure and an impediment to scaling until late in 2011 when they allowed for up to 25 load balanced listeners to register at the same Receiver endpoint. This was great for redundancy purposes, but what happens if your connection to the service bus goes down? Well, then, basically all your consumers will start failing as they can’t reach the service.The biggest thing, in my opinion, that the Service Bus Relay is missing is actual routing of messages and/or events. Sure it connects a point to point communication, but it doesn’t really live up to what I consider a Service Bus. For direction communication or tunneling traffic scenarios the Relay makes a lot of sense, but for a mechanism for decoupling systems it seemed like it is missing something… like durable messaging and scalability on the consumer side. Enter: Service Bus Brokered Messaging.Image: Windows Azure Bootcamp Materials – Used here under Creative Commons Attribution NonCommercial license. http://www.windowsazurebootcamp.com
  • Enter Windows Azure Service Bus Brokered Messaging. Whereas the Relay service is to just relay a communication point between two systems, the brokered messaging is meant to fully decouple the communication between the systems. This also allows us to start to look at thinks like routing and publish/subscribe, but I’m getting a head of myself.If you were going to compare the two queuing mechanisms you must first do so in an apples to apples approach; that is, compare base queuing functionality of both technologies. Service Bus Queues have features that go beyond the standard push a message, get a message and remove a message from a queue, but let’s start with the basics.So the simple Service Bus Queuing works like this: messages are entered into the queue from one or more producers. These messages are then pulled off by one more consumers. Sound familiar?
  • Demo the Windows Azure Service Bus basic Queue.Simple creating a queue, adding to it and getting a message out.I left out how to create a Windows Azure subscription, as well as how to create a Service Bus Namespace. If you want to learn more about those check out:Windows Azure Subscription: http://www.windowsazure.com/en-us/pricing/free-trial/ Windows Azure Service Bus Namespace: http://msdn.microsoft.com/en-us/library/windowsazure/hh690931.aspx
  • While the two approaches don’t appear to have any real differences, the devil is in the details about things. Let’s compare more a little later, but for now let’s talk about the additional capabilities that the Service Bus Queues have.Image: Stu Willis, Used under Creative Commons Attribution, NonCommercial Share Alike License.
  • What happens if no one is listening to a queue?The features for Windows Azure Service Bus Queues don’t stop at just being a queue, there is also the feature referred to as Topics. Topics are a publish/subscribe mechanism where consumers of messages can subscribe to messages coming into the system.Here’s a question for you: “If messages are submitted to a queue and no one is around to deal with them do they make a noise?” (Joke - http://en.wikipedia.org/wiki/If_a_tree_falls_in_a_forest). Well if they are sent to a queue then you expect them to stick around till someone comes to process them (at least for some period of time). If they are sent to a Windows Azure Service Bus Topic then they will simply go into the ether. That might not sound like a good idea, but this is where subscriptions come in. If you create a subscription to a Topic then a copy of the messages will be delivered to the subscription. If you create multiple subscriptions then a copy of each message will be placed into each subscription and then each subscription can have it’s own consumers. Also, you have the capability to filter what a subscription receives based on message metadata.One good example usage of this is to route all messages to a topic with a subscription that is for auditing and then have other subscriptions set to receive messages only meant for it based on metadata. Now we start to see the routing capabilities of an Enterprise Service Bus.
  • Demo the Windows Azure Service Bus Topics and Subscriptions.Create a topic, send messages to it, create a subscription, send messages to the topic and see the message from the subscription. Create another subscription with a filter. Send more messages to the topic and see the subscriptions get their messages (with one being filtered).
  • See http://msdn.microsoft.com/en-us/library/windowsazure/hh767287(v=vs.103).aspx for more details.
  • See http://www.windowsazure.com/en-us/pricing/details/ for up to date details.
  • No presentation, article or book is a replacement for critical thoughtSo a question I hear a lot is, “which one should I use?”. That’s a very loaded question and it is about like asking, should I use .NET or ObjectiveC? Should I buy an iPhone or a WP7 device? Both technologies can do simple queuing. Beyond that they each have features the other doesn’t and you’ll really need to understand what you require for your solution to determine which one to pick. Granted, the Service Bus queues have more features, but there may be some things that the Storage Queues give you that the Service Bus queues just don’t do (such as updatable payloads).My goal today was to arm you with the information you need to make good decisions on which technology you need, not to dictate which one you should use. No presentation, article or book is a replacement for critical thought.Image: tshein - Used under Creative Commons Attribution License - http://www.flickr.com/photos/drnewton/517371624/
  • A Queue By Another Name

    1. 1. A Queue By Any Other Name Would Still Work The Same ... Or Would It? http://mvwood.com @mikewo on TwitterImage: xkcdefg.com
    2. 2. Image: Donald McCleod
    3. 3. Image: ShellyS
    4. 4. Windows Azure Queuing Technologies
    5. 5. In the beginning…
    6. 6. Demo ….The part where I attempt a technology feat of incomparable simplicity.
    7. 7. A word about visibility and idiopotentcy idempentacy idempotence…* Gratuitous animations do NOT equate to a better presentation, but do clap, they’re hard to put together…
    8. 8. Then came Windows Azure Service Bus Queues…Image: John Ward
    9. 9. Image: Axel Angeli
    10. 10. sb://stringreversalinc.servicebus.windows.net/processtring Backend Naming Routing Fabric Service Bus Relay Messaging Frontend Nodes Sender ReceiverImage: Windows Azure Bootcamp Materials
    11. 11. So, what does Service Bus Queues look like?
    12. 12. Demo ….The part where I attempt a technology feat more complex than the last one, which I hoped worked otherwise I’m in real trouble this time
    13. 13. In the event of demo failure, simply applaud and produce generous amounts of ooohhhsss, and aaaahhhs, so that others outside this room will believe everything was a blazing success. If the demo worked, apply the same reactionImage: Stu Willis
    14. 14. Service Bus Topics & Subscriptions Topic Subscription C (Filtered) Subscription B Subscription A
    15. 15. Demo ….Add witty remark here…
    16. 16. Storage Queues Service Bus Queues Up to 64K Message Size Up to 256K + Sessions No Long Polling Yes Up to 7 Days Message TTL Up to basically forever Up to 100 TB Queue Capacity Up to 5GBStorage Credentials Authentication ACS – fine grained Yes REST API Yes, not all features Yes Flexible Lease/Lock No Automatic No Yes Deadlettering No Dup Checking Yes Yes Purge No
    17. 17. Storage Queues Cost Service Bus Queues 1 cent /100K Transactions 1 cent / 10K *** All Billable Ops Send / Receive Billable Idle Transactions Billable $0.125 * / GB / Month Storage $0.00 Standard WAZ Price Bandwidth Standard WAZ Price N/A ACS $1.99 / 100K Tokens **Prices as of the time 8/04/2012 – check prices online for current.* Tiered pricing, starts at this price.** Not charged until Dec 1st 2012*** messages over 64K may cause a transaction per 64K
    18. 18. Image: tshein
    19. 19. http://mvwood.com @mikewo on Twitter Thank You… http://spkr8.com/mikewoNo animals or developers were harmed in the creation of the animations