I need to subscribe to a third-party web socket feed and process the messages received (e.g. write them to a queue).
I'm testing the service locally with a C# Windows Console application and it works just fine: I subscribe to the feed, I add even handlers, and then I do Console.ReadLine() in order to keep the application running and listening to the feed.
Now I need to deploy it to Azure. So my question is - what Azure service is appropriate for this scenario? That is, I need to deploy, subscribe to the feed and keep it running.
Azure Cloud Services is what you're looking for. This is (as of right now at least) their official always on service for your use case. It is a managed windows service, meaning that it will manage making sure that your service is running and bringing it up and down. You can set auto-scaling if you need it.
Read more here
One option is to deploy a Windows service to a virtual machine, but that could be an overkill.
The other alternative is continuous web jobs.
Related
I have a service, (.net core 3.1), that receives messages, a lot of them, and stores them in a DB.
The original is baked into an API and deployed as an App Service.
The App Service works fine. Great for the API and the Web but I'm uncertain whether it's the best choice for the service which I now intend to separate from the App Service. It's more or less background worker that just collects data and saves it.
I would like to know if there are any other more suitable Azure products other than App Service or should I go with another App Service?
It seems your use case basically fits to serverless scenario. All your messages processing can be handled by Azure Function.
https://learn.microsoft.com/en-us/dotnet/architecture/serverless/serverless-business-scenarios
https://learn.microsoft.com/en-us/dotnet/architecture/serverless/serverless-architecture
I am completely new to using Azure so I could use a little advice. Here is my scenario. I need to develop an application that was originally thought to be a windows service but is now to be deployed to Azure. The app is a scheduling application that reads from a DB and calls a couple of different APIs when it's time to either start or stop an event. The DB will be stored in Azure as well.
Initially, this sounds like a WebJob, but the issue is I also need for the app to be both host and client for a SignalR WebSocket. The intent of this is to have two instances communicate with each other and a backup self-promote if it loses communication with the primary. My understanding is that WebJobs don't support things like WebSockets.
Is there an Azure service that would work well for this. I can use a virtual machine but would like to avoid it if possible. Any help is appreciated. Thanks.
I think you're looking for this one:
https://azure.microsoft.com/en-us/services/signalr-service/
Docs:
https://learn.microsoft.com/en-us/azure/azure-signalr/signalr-overview
Sample code:
https://github.com/aspnet/AzureSignalR-samples
I am trying to implement SignalR hubs on my REST service (ASP.NET Web Api) hosted on azure. I've been reading some common stuff related to SignalR and I came to this one that it is server bound. You can check here. Which means that in order to be able to scale it on multiple server instancs I have to do some additional stuff. So, then, I started to ask myself "How many instances do I currently have running of my REST service on Azure? How do I know that?"
So, what I did was - I navigated to azure portal and opened my service > Process explorer
Does that mean than my web app scales automatically and I currently have 2 instances of my web api runing? I think it clearly says that there's currently only one instaces of it running 2 processes but how do I know if it will scale some time in the future?
No, your photo shows your app process and Kudu, which is a management interface you can access at https://yourappname.scm.azurewebsites.net.
You can see the instance count in your app's App Service Plan. If it is on Free or Shared, there can only be one. If it is Basic/Standard/Premium, it is one by default. If you haven't setup auto-scale, it won't scale to more than 1 instance unless you tell it to.
I'm currently developing a SOA based architecture in Azure, using disparate Web API services (they'd probably qualify as Microservices, but I'm hesitant to use the term).
I have a service which is triggered by the Azure Scheduler. It does some "stuff" and then needs to call another Web API (via HttpClient) service to trigger something else. To do this, I need to know the URI of the 2nd service. When running locally, this is fine, as it is something like
POST http://localhost:1234/2ndService/api/action
However, when I deploy to Azure (using Internal Only as the access level), it gets an obfuscated URI, such as http://microsoft-apiapp8cf3d453-39d8-4b3b-ad00-e9d8008a9b58, which I obviously can't guess at deploy time.
Any ideas on how to solve this problem? Or have I made a fundamental error here?
Instead of relying on public http endpoints, have you considered passing messages via queues in Azure Table Services? It's very simple to do and is going to be more robust since you can take advantage of built-in features like guaranteed message delivery.
The overall idea is that Service A does some "stuff" then puts a message on queue ONE. Service B continuously reads from queue ONE until it picks up a new message from Service A (or any other service for that matter) and then does its "STUFF". You can continue to chain calls like this to other services that need to be notified.
If you want a more elegant solution you can look at using Service Bus Topics but the concept is basically the same.
Also, since you mentioned that your architecture is much like microservices, you can check out the new Service Fabric which is designed for your scenario.
In case of Azure Web Apps, you may always see such properties going to the web app dashboard, then properties. When deploying from the Visual Studio, you can set the URL as you want - just checked it, and it works fine.
Not very clear what technology do you use - is it IaaS VM? Is it Web Apps?
From my standpoint, each service should be deployed as a separate Web App (or API App, if you want). Each Web App has defined its own name as in yourwebapp.azurewebsites.net, so once you have provisioned the Web App no 1 in Azure, you know its address so you will call it from the Web App no 2.
In all the cases, you should have fully qualified domain names, and not local/internal ones.
I have developed a windows service. i need to deploy it in Azure App Service. Please someone explain me how to do that. Is there any way to install it on console or any other option.
You can't deploy a Windows Service using App Service. One option is to convert your code into a Web Job. Another option is to use a Virtual Machine instead of App Service.
Azure App Service is the service that should be used for Web/Mobile and basically is the web-server-as-a-service. You have almost no access to the underlying system, and system-wide actions like a working windows service is likely impossible.
I see three ways:
1) Migrate to Worker Role, but it is classic model. There is a good article on how to do that, i took a look and did not see any potential problems. It is more simple way.
2) Migrate your windows service to Web Job and run it as a background service. It will need you to rewrite some parts of your service, i think - but there are supported executable formats out-of-the-box. Take a look at how it works.
3) Take a look at Azure Functions - it is "trigger-and-invoke" service that can be used for listening for events and executing actions.
But, if you need to catch some events from DB, then i am not sure that it will be possible with that, because Web Job is more like a service that listens for external events, and yours scenario looks like you want to catch events from the same server. That way, i would recommend you to place it on a virtual machine to avoid the rewriting or migrating time-consuming issues.