Azure Web Jobs are a big time saver in that they solve the plumbing of triggers, continuous running, dashboard, etc. But I've only seen them run in Web sites. It'd be great to be able to move them to a Worker Role. Do you have suggestions about how to do it?
I'd personally love to see how they implement it, so that I can replicate it in my worker role, without reinventing the wheel...
The answer to the main question is No Azure WebJobs are part of Azure Websites and only run in an Azure Website context/host.
But Azure WebJobs SDK which is an SDK that allows you to write code that is triggered on Azure storage blobs/queues and Azure service bus queues including some great logging capabilities, can be used outside of Azure WebJobs and so they can run anywhere (locally, VMs, WebRoles).
It is important to understand that Azure WebJobs are a framework that is part of Azure Websites that allows (almost) any console application (and .bat, .php, .js, ... scripts) to run continuously or triggered (manually/scheduled).
WebJobs SDK and WebJobs are not dependent on each other although they work great together.
Also to see how it's implemented go to https://github.com/projectkudu/kudu as it's open sourced (for now The WebJobs part, SDK may be open sourced in the future).
Yes, you can use Azure WebJobs outside of Azure Web Sites. You use the Azure WebJobs SDK to do so. There is a sample on MSDN on how to use the SDK in an console app. It then goes on to host it in a web site, but you can of course host it in other ways. There is another article, "Hosting Azure webjobs outside Azure, with the logging benefits from an Azure hosted webjob" that explicitly talks about using WebJobs outside of Azure. With a little work this should work in a Worker role as well.
I'll stipulate that I've not actually done this myself, but the SDK does make it possible.
I'd also recommend this treasure trove of resources for WebJobs.
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.
I have a console application connecting to database and executing DML transactions. This console application is currently scheduled using windows task scheduler. I am planning to migrate this to Azure.
Which is the recommended strategy ?
Should this be moved as Azure webjobs or function apps ?
Since you already have a console project, then it's more easier to use Azure Webjobs to achieve that.
To create a webjob, just create a .zip file which includes the .exe / .dll and other necessary files, then upload to azure. For schedule, please refer to Create a scheduled WebJob. For more details, you can refer to this doc.
Note: there're some limitation of azure webjobs / azure function, see Azure-Web-App-sandbox. But if you only need to connecting to database and executing DML transactions, you can ignore the limits.
And yes, you can also do this via azure function, but since you already have a console project, it's easier to use webjobs.
I am currently looking into using ARM to deploy new environments of our Azure Components. We have a lot of web apis that are deployed to Cloud Services, since we need access to the underlying OS to get CPU usage for App Dynamics metrics. When reading through ARM, it seems as if they are deprecating Cloud Services, but I have some confusion about what is replacing it. I see that you can create Web Apps using this and use Publish from Visual Studio to deploy the app it, but I see no options for Cloud Services. So what is the preferred method to do this? Creating a VM and deploying using Web Deploy? What about VM scaling. Any help would be greatly appreciated.
My company is in the process of moving a legacy app to Azure using Cloud Services and we were concerned about the future of Cloud Services. Since we are somewhat early into the project and would like to use the ARM model we thought it would be easier to make a move now if we knew the future. After a few conversations with project leads at Microsoft on this topic we were only told that we should continue working with Cloud Services as they would continue to be supported.
It's quite clear that the move to ARM was not well thought out in terms of direction and consequences of existing services that many people are already using. Reading between the lines I would say that there is no plan to convert Cloud Services from the ASM to ARM model.
If application insights (https://azure.microsoft.com/en-us/services/application-insights/) are sufficient for your monitoring needs, then you can use web apps. These can be deployed via ARM, and can automatically deploy from a git repo or web deploy package. See this example:
https://github.com/Azure/azure-quickstart-templates/tree/master/201-web-app-github-deploy
The issue here that you may be trying to do operations which are restricted by the web app sandbox.
Failing that, you can use an ARM template to set up a VM and then invoke a custom site extension which will run powershell code to do further provisioning. This powershell code can fetch any package that you may want to install. See this ARM template for example: https://github.com/Azure/azure-quickstart-templates/tree/9ad72f1f5f0008c14311be79eee036b871712394/201-list-storage-keys-windows-vm
Once the VM is created you would be able to modify it and scale as needed.
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.
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.