This question already has answers here:
Test Azure Service Bus locally without any subscription or login
(2 answers)
Closed 4 months ago.
By any means is there anyway we can try Azure Service Bus on Local Machine to send/receive messages without any Azure Subscription?
I meant like Postgres which can be installed on PC and try CRUD operations from C# code , in the similar way for Azure Service Bus.
In 6 April 2021 #jimmy-bogard said:
For teams new to Azure Service Bus, one of the first questions you have to answer is "how do I develop against this?" And it turns out the answer isn't that straightforward - because it's currently impossible to run Azure Service Bus outside of Azure. There's no install. There's no Docker image. There's no emulator.
I don't think something changed from that time. In my project we use RabbitMQ for local development. And than use Azure Service Bus in deployed services
Related
My app needs a background service that constantly receives and handles events streamed from an Azure Event Hub.
I see that Azure Functions has built-in triggers for this, but the problem is that my app is written in .NET 5 and Azure Function support for it is fairly immature at this point.
I also see from this documentation that .NET has an readily-made SDK Azure.Messaging.EventHubs. My understanding is that this will run as a console app.
I'm already using the Azure App Service (Linux plan) to host the main web app.
So if I create a console app using Azure.Messaging.EventHubs, I'd want to deploy it as something like a web job, but the Linux app service plan doesn't support it. I guess I can deploy the console app it to a separate Windows App Service plan.
What's the next best option? Are there any practical differences compared to using Azure Functions?
There's also this .NET Core Worker Service that's more optimized for background services. I wonder if there's a place for it in this use case.
These options are confusing me a bit. Your advices would be greatly appreciated.
Azure function should be the best choice. It has the built-in eventhub trigger and process logic, and easy to setup / configure(like logging via Application Insights) / less code to write. And recently(Mar 10 2021), it is supported for running production .NET 5 apps on Azure Functions. I suggest you can give it a try and use it if no issues.
For azure webjobs, in this case, if you're directly using the SDK, you need to write many codes and configure something like logging.
For .NET Core Worker Service, it can also be published as azure webjobs if you want to use it. You can follow this doc on how to publish worker service as azure webjob.
We are migrating to Azure. We have a Web App deployed. However, I have a Windows Service that I need to add in to the mix. The service continuously runs, checking the associated Service Bus Queue for messages every 5 seconds.
I am looking for recommendations on how to do this.
I have looked at Web Jobs. But, I don't understand how it gets kicked off. I know there is a Web Hook involved - but I just want the code to run continuously without having to be constantly kicked.
We are also trying to avoid the cost of having a VM involved.
Thanks in advance.
Since you already have a web app, you could use a Azure App Service to run the Web App. The Azure App Service will allow you to also have a Web Job that you can have run on a schedule.
It does not make sense to break you web app into Azure Functions since it is already built. You can have the service run in an Azure Function, but it will probably add more complexity to interact with the web app (if that is what is happening) and if the service is running every 5 seconds, that could get costly.
I am writing an application that will be deployed both to the cloud and to on-premise data-centres (for those clients who, essentially, don't yet trust the cloud with their data.
If i choose to go MS Azure I can use the new cloud project types with their Web and Worker roles. But how can I get the worker roles running for the on-premise variant?
Do I have to write my own host (say as a windows service)? This is not ideal as it requires additional code and deployment.
Is there an Azure compatible approach, say in the Windows Azure Pack or the App Fabric stuff (is App Fabric still current?) that doesn't require the full setup of the private cloud ?
This doesn't exist in Azure Pack.
There is no need to try and have a Worker Role on premise. All you need to do is to have a Virtual Machine that you install a Windows Service on.
It's easy to create a Windows Service using Topshelf.
Deployment of a Windows Service with Topshelf is actually much easier than deployments for Worker Roles because you just run the .exe you create with the install and then with the start arguments.
Because of this you actually need less code than for a Worker Role since you don't need a second wrapper project.
While I haven't used Windows Azure Pack before it does seem capable of providing this functionality in house, however the requirements and setup procedures are intense and it is certainly geared towards enterprise.
A better option is for you to create a console app that triggers the OnStart() and Run() functions for your WorkerRole based on your OS Task Scheduler.
Not too much work in my opinion and you get to keep your WorkerRoles as is but just add the console app for any on premise solutions.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
What is the recommended way of deploying a single Windows Azure Cloud Services application to multiple data centers?
Should I put an existing app on hold in all data centers, then after deployment is complete re-enable them? Or there is a better way doing this?
Ideally I'd like to have an ability to set in a Windows Azure cloud project's config file the list of data centers so that during a single publish operation the app would be uploaded to multiple data centers simultaneously (for example North Central US, West Europe and East Asia data centers).
What you have described will require a bit of custom deployment logic. I would recommend that you get familiar with PowerShell and the Windows Azure Management Cmdlets. A bunch of examples for how to deploy packaged with PowerShell are available on Github.
I would upload your Azure package and service configuration files to each host service's staging slot that you have in each datacenter (i.e. your multiple datacenters) using the same PowerShell script with different arguments for each hosted service. You'll need to have some custom wait logic that polls the status of the staging slot deployment and waits for the READY status. Once this is complete you know your VM is ready and if your application load quickly you can then perform a VIP Swap using PowerShell as well.
The PowerShell commands that you will need to accomplish this are the following:
New-Deployment (Use this to deploy to each of your datacenter's hosted services)
Get-HostedService (Use this to get the status of your newly deployed hosted services)
Move-Deployment (Use this to perform a VIP Swap once all your staging slot deployments are ready)
Note that even when you build this there is a chance that things will be out of sync for a few seconds at best and a few minutes at worst so your new deployment will always need to be backwards with your underlying data storage systems/schema.
I'd recommend using the Windows Azure Service Management REST API for this. PowerShell tends to be repetitive and slow for multiple deployments (i.e. the package is uploaded to storage for each deployment, even if it is the same package). There is a great and complete example on using the REST API at Windows Azure ServiceManagement Sample. We have extended this sample for a similar situation: We have 45+ microsites using the same code base and use the REST API to deploy to each service instance asynchronously. We upload the package to an Azure Blob and then trigger an asynchronous update of each service using the Blob URL. With the REST API, you can run your updates from a build server or an Azure Worker Role.
I have several web and worker roles in my solution, but I also have a non-Azure application running on a Azure hosted VM. That application connects to Azure storage for various things like reading and writing blobs and queues, and that works fine.
I'd like to use Azure diagnostics from within that same application (a .NET app running on a VM hosted in Azure). However, if I try to initialize diagnostics I get an exception that:
System.InvalidOperationException: Not running in a hosted service or the Development Fabric.
This makes sense, but I'm wondering if it's possible to use the diagnostics in some way without being a hosted service. In particular, I'm using azure diagnostics to gather logging information, written out by System.Diagnostics.Trace, and that's all hidden away from the application code, so if there were some other APIs I have a place I can probably slot that in.
Any ideas?
Thanks,
JC
Unfortunately, no. At least not today. The agent has some hard-coded checks for the RoleEnvironment stuff and when it is not there, it fails. This is also the reason you cannot use the agent in the IaaS stuff today either.