I have a .NET web application that is deployed as a multi-instance Azure Web App. This web application makes use of SignalR to broadcast messages to connected clients. I'm scaling out using a Service Bus backplane, and this works great.
I also have a continuous WebJob that monitors a Service Bus queue, does some intensive processing, and as part of that processing needs to send out a broadcast message to SignalR clients.
It seems that there are two ways I can go with this:
Treat the WebJob as a SignalR client by connecting with my SignalR Hub running on the Web App using a HubConnection and an IHubProxy. This seems to work well, and is what I'm currently doing.
Somehow treat the WebJob as another Hub, and add it to the Service Bus backplane. I am not sure how I'd do this. I would then just broadcast messages using an IHubContext that I get from the SignalR.GlobalHost.ConnectionManager.
My questions are:
Is one way of doing this substantially better than another?
If option #2 is better, can someone post a link to how I'd go about doing this? It seems that most tutorials are in regards to a multi-instance scale-out using either SQL Server, Service Bus Topics, or Redis as the backplane.
Related
I'm trying to figure out how to connect my angular app to azure service bus. The reason I'm trying to do this is to setup real-time pub/sub solution for live auctions. I haven't really seen any start to finish documentation/tutorials on this with MEAN stack so I'm trying to piece it all together. In order to connect to my nodejs backend, what should I be using in Angular to make that connection? All the tutorials I see are referencing SignalR, but they are using .net. Is there a library that is equivalent for Nodejs or do I need to be using something like this?
I appreciate any help/direction!
It's not entirely clear if you are trying to connect your Angular front end to Service Bus as a replacement for SignalR. If so, it isn't a good idea as it would create a serious security hole. Service Bus is primarily for communication between servers. In this scenario, if you had multiple back end node servers, you could use Service Bus to sync the data they are pushing to your clients.
You are going in a better direction with SignalR. The technology you are looking for in real time server-browser communication is websockets. SignalR is just a .NET implementation of that standard. Once you start looking for websocket implementations on the MEAN stack, you should have a lot more success in finding guides. Here's a couple for generic JS implentations just as an example: Link 1 Link 2.
Edit for comment response:
You don't want to connect angular to Service Bus at all. Once you've exposed the keys publically, anyone can read/write whatever they want to your bus. Instead have Angular send the message to a HTTP function and have the function send the message to Service Bus.
The second problem with this plan is that websockets connections, the part that pushes data back to the client, is a long-running connection with constant communication back and forth. The consumption and premium plans are not built for this. Trying to use websockets on those plans will run up your costs a lot higher than they need to be if you have any significant traffic. You'll need to choose a plan that has a flat monthly cost instead. At that point you could still use Functions, but it may be easier to use a traditional web app.
In this case your system would look like this:
Angular new message -> HTTP Function/Web App -> Service Bus -> Websocket Function/Web app => Angular
If you are only running a single server, you can eliminate Service Bus completely.
The other option is to still use a HTTP function to receive new messages, but then use the SignalR service (not the .NET library) to handle pushing the data to the clients. This elimiates Service Bus as well.
This is what it would look like: Angular new message -> HTTP Function/Web App -> SignalR Service->Angular
I have a local machine that reads RabbitMQ queue messages.
I wish to move it to cloud. Which Azure service can be used in this case?
I went through event hubs, but I am not sure, if it would read messages from rabbitMQ continuously.
Any suggestions for the service that should be put to use.
You should take a look at Azure Service Bus. It has got FIFO queues as well as publish/subscribe capabilities. However if using Azure managed service is not a strict requirement you can use RabbitMQ on a VM (or a cluster for high availability) as well.
UPDATE: Your response means you want a managed service. There are 2 options - if you want to go with RabbitMQ but do not want to manage the infrastructure you can go for 3rd party service provider like CloudAMQP who will manage it on your behalf. The other option is to go for Cloud native messaging - meaning if you are on Azure you change your messaging service to Azure Service Bus. This would mean changing you code as well.
I have implemented a Proof of Concept in Azure Service fabric that uses Azure Service Bus as a message queue. I'm using nServiceBus within the application to send and respond to messages which makes it very easy to change from one queuing technology to another.
I'd like to know if it's possible to use MSMQ instead of Service Bus in Azure Service Fabric as the nodes that are created are just windows 2016 servers and I'm not sure I need something like Service Bus. It's a question I want to answer with my POC.
Does anyone know whether MSMQ is included in an Azure Service Fabric node or how I could turn it on and if it's a viable solution?
Short answer - MSMQ is not suitable for Azure Service Fabric.
MSMQ is store and forward technology. It's using local file system to persist messages and then forward to another machine. When Service Fabric is going to move service from one node to another, it will not move the file system along. Meaning you'll lose messages.
I would recommend to stay with Azure Service Bus unless there's a good reason you're looking for an alternative.
we are planning to use SignalR with Windows Azure Service Bus for a cloud application that requires live client updating (browsers). We might have about 200 clients connected to our solution. If we deploy our application over a 4 instances cloud service I know I should use the "GlobalHost.DependencyResolver.UseWindowsAzureServiceBus(connectionString, 1);" option to connect them through the service bus.
My question is: Will it use service bus relays? or topics? as many as hubs on each instance? one relay per client (200 clients) connected using SignalR? I just want to know how much they will charge me to know if it is worth it. In fact the most important thing to know here is if SignalR uses Topics/subscriptions or relays?
Thanks a lot for your help,
The SignalR Azure Service Bus scaleout provider will only use one subscription per role instance. If you have 4 cloud service instances, you will actually want:
GlobalHost.DependencyResolver.UseWindowsAzureServiceBus(connectionString, 4);
The second parameter is your instance count.
This will put all of your SignalR messages on one topic. If you want to distribute you messages between more topics, you can specify a topicCount as the third parameter to UseWindowsAzureServiceBus like so:
GlobalHost.DependencyResolver.UseWindowsAzureServiceBus(connectionString,
instanceCount: 4,
topicCount: 2);
NOTE: The parameters above are only named for clarity.
We are looking to use Windows Azure to host our existing SaaS platform and extend our functionality and capability. WE will be taking adavantage of both the data storage and application and web service functionality of Azure.
My question is as follows:
Some of our clients will not want Public CLoud access. Since our datastore stores sensitive client data many of them will require our whole system to be hosted internally on their own network and servers.
If we setup a full Azure setup of database and connected applications and processes how difficult is it to be able to duplicate that system for a specific client on their own servers and network using existing Microsoft technologies?
I know its a vague question and I also have a liminted understanding of Azure so whatever information you can provide here would be most appreciated.
Thank you
It sounds like you need the flexibility of a hybrid cloud/on-prem solution. Likely the best solution is the Windows Azure Service Bus. Essentially, you configure a WCF web service in the cloud (SOAP, REST, etc) that performs asynchronous brokered messaging between your on-premise application and your web application. This can be performed using queue messages, for example:
The web application (cloud) requests resources from the brokering service (cloud) by sending a queue message
The service handles the queue message and makes it available to the consuming (on-prem) service
On-prem service checks for new messages from the brokering service, gets the request for data, and returns desired data from DB
On-prem service sends message to brokering service with desired data
Web app (cloud) checks for new messages from the brokering service, then uses the data from on-prem service
Service bus is secure, asynchronous, fault-tolerant, and ensures that both components are decoupled.
Another method is to use Windows Azure Connect, which is a VPN solution that sets up network-level connnectivity. I recommend Service Bus because it promotes a more robust and scalable architecture, and fault-tolerance is high.