Azure Infrastructure for Asynchronous Processing
This article's main focus is on the infrastructure provided by Microsoft Azure for seamless processing.
Article on Asynchronous Processing can be found here ☺️
Microsoft Azure provides us various things for application to work in bits and pieces. It helps in managing long-running processes;
Azure provides:
Microsoft Azure provides us various things for application to work in bits and pieces. It helps in managing long-running processes;
Azure provides:
- Azure Service Bus (Messaging)
- Topic
- Queue
- Storage Queue (Storage)
- WebJobs
- Function Apps
- Service Fabric
We'll also try to touch on Microservices.
There is one confusing part we need to understand is Queue... As it is in the Azure Service Bus as well as in the Storage.
Azure Service Bus has Topics and Queues.
Storage has Table, Blob, File Storage and Queues.
The major difference between storage queues and service bus queues is well documented here.
In this architecture as well we need an end-point to which consumers will hit and a message will go to a queue, which will be consumed by either Web job or Function job.
Here the crux is we have three (we can say four as well) different components in picture and neither client is waiting nor server (end-point) is waiting. Because the end-point will work as an arbitrator between the client and the actual processing component.
Client ---> End-point ---> Queue/Topic
So the job of end-point is to pass the request to queue or topic as they need it.
Now... Either our Web job or Function app (our implementation) will pick the message from the queue and keep processing.
The obvious question that comes in mind after reading this line is, then how to track the processes... Isn't it?
If you went through the differences between the Storage queue and Service bus queue, you would easily understand that we should go for Storage Queues, as it gives us the proper log of processing that happened against the message.
I think you need a tea break... You covered a lot...
You back...? Great...
Its time to understand the difference between Azure Web Job and Azure Function Apps.
This article is yet to be complete.
Reference:
https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted
The major difference between storage queues and service bus queues is well documented here.
In this architecture as well we need an end-point to which consumers will hit and a message will go to a queue, which will be consumed by either Web job or Function job.
Here the crux is we have three (we can say four as well) different components in picture and neither client is waiting nor server (end-point) is waiting. Because the end-point will work as an arbitrator between the client and the actual processing component.
Client ---> End-point ---> Queue/Topic
So the job of end-point is to pass the request to queue or topic as they need it.
Now... Either our Web job or Function app (our implementation) will pick the message from the queue and keep processing.
The obvious question that comes in mind after reading this line is, then how to track the processes... Isn't it?
If you went through the differences between the Storage queue and Service bus queue, you would easily understand that we should go for Storage Queues, as it gives us the proper log of processing that happened against the message.
I think you need a tea break... You covered a lot...
You back...? Great...
Its time to understand the difference between Azure Web Job and Azure Function Apps.
This article is yet to be complete.
Reference:
https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted
Comments
Post a Comment