In this video, learn about the Azure Storage queues, including the benefits, workflow, and considerations of using this service. The demonstration details how to create an Azure Storage queue.
- [Instructor] Azure Storage Queues can also be used as a messaging solution instead of the Azure Service Bus Queues messaging options. Azure Storage Queues are not part of the Service Bus service, but fall under Azure storage. These queues are designed for message queuing of large workloads and use asynchronous communications, or one-way communications, for a variety of senders or front ends, including cloud, desktop, an on-premise server, or mobile devices.
Let's go ahead and take a look at a simple workflow. Let's imagine we are ordering several items from an online store. We submit our order, and the order will then be placed in the queue. We receive an email letting us know that the order has been submitted for processing. Now the backend will work through the orders in the queue and start processing them. During processing, the order is locked, preventing another backend receiver from processing the order.
Once processed, you'll receive another email letting you know that your order has been processed. Once the order has been processed, it will be removed from the queue, ensuring that your order will not be processed more than once. When using storage queues, there are a few considerations that you need to be aware of for your messages. First, the storage queues use a REST-based GET/PUT/PEEK interface. And just like the Azure Service Bus queues, messages use a sequencing method of first in, first out or FIFO.
The maximum message size is 64 kilobytes, just the same as those Service Bus queues, but the messages can only live in that queue for seven days. As you may recall, in the Service Bus queue, the default was 14 days. Let's look at some of the highlights of queue processing. Messages can be accessed using HTTP or HTTPS calls, and they are processed one at a time, and they will be locked during processing.
After processing, the message will be deleted, and you can have as many messages as the capacity of your storage account. Remember, with the Service Bus queues, we could have a maximum queue size of five gigabytes. Let's go ahead and take a look at the storage queue anatomy. Say that we have our storage account. In our example here, we're calling it User One. Within that storage account, we have a queue that we've called Orders. And, within that queue, we'll have the messages, and they'll contain items such as CustomerID, OrderID, etc.
And the URL, which I have listed at the bottom of the screen, would be https://user1.queue.core.windows.net/Orders. We discussed Service Bus Queues earlier in this chapter, and you may be wondering, when to use a Storage Queue instead of a Service Bus Queue. If you need to store over 80 gigabytes of messages, you will use the Storage Queue, and as we've already mentioned, if the message lifetime will be less than seven days, you can use the Storage Queues.
We can track the progress of processing the message within a Storage Queue. And finally, if you require server-side logs, you'll need to use a Storage Queue. Here are only a few reasons why you'd use a Storage Queue over a Service Bus Queue. But there is an extensive list on the Azure website that compares the two services in detail. Let's go ahead and create a Storage Queue in Azure. I'm going to continue to use our LiLMessaging resource group, and notice here, that we have a Service Bus already in that resource group.
Let's go ahead and add in a storage account. To do so, I'm going to go ahead and click on Add. You can either search for storage or, as I can see here, the Storage account has been suggested for me. The storage account blade will pop up. I'm going to go ahead and click Create. We need to provide a name for our storage account. This must be a unique name. I'm going to call it lildemo. I'll use Resource manager. I'm going to leave the Account kind as general purpose, Performance as standard, but I will change the Replication to locally-redundant storage.
I'm going to use the existing Resource group, and I'm going to go ahead and click Create. If you'd like more details on these settings, please see the associated Azure courses on Storage. This will take a moment to create. Our Storage account has now been provisioned. I'm going to go ahead and close these blades. I'm going to go ahead and refresh the resource group. And we can see, our Storage account has now been created.
Let's go ahead and create a queue. To do so, I'm just doing to scroll down, find the Queue service, click on Queues, and then add a queue, and then provide a queue name, and click OK. Within the portal, I can go ahead and add a message, set the expiry, and depending on your application, you can choose to encode the message body in Base64. I'm going to go ahead and click OK. Now, typically, you would not be doing this through the portal.
You'd be managing those message through your applications. To quickly recap, Azure Storage Queues are actually part of Azure Storage, and they are designed for message queuing of large workloads.
- Creating compute-intensive applications
- Creating long-running applications
- Implementing messaging systems
- Azure Service Bus relays
- Using Azure Storage queues
- Creating an Azure Event Hub
- Creating Azure WebJobs
- Managing cloud environments with Azure Active Directory Domain Services