I've written a Node app that essentially serves as a Task Scheduler (or cron) to run batch processes on set time intervals using node-schedule. When I run this program locally or on a VM, the process will run continuously and execute my jobs until the process is forcibly killed. When I deploy this app to Azure as an Azure App Service, the process is treated more as a "Web App", and after a period of inactivity on the site (ie no web traffic), Azure kills the process. If I access the "site" via a browser, it kicks it back up again.
It seems as though Azure is tied to the Node app being an express-based "web app" and as far as I can tell, there's not a way to deploy my command line app in a reliable manner. Am I missing something or is there a better way to deploy this application in Azure either via Web App, or another offering? Would really like to avoid having to maintain a VM just for this purpose.
For your immediate problem of idle timeout there is a simple configuration available called Always on. Take a look at the link here - https://learn.microsoft.com/en-us/azure/app-service/web-sites-configure.
Always On. By default, web apps are unloaded if they are idle for some
period of time. This lets the system conserve resources. In Basic or
Standard mode, you can enable Always On to keep the app loaded all the
time. If your app runs continuous WebJobs or runs WebJobs triggered
using a CRON expression, you should enable Always On, or the web jobs
may not run reliably.
Also look at cost implications discussion here - Does the Azure Websites "*Always On" option have any implication on price?
Now whether App Service is the best solution or not for your problem of Task scheduling, is a more subjective and longer discussion, where you need to evaluate multiple offerings that Azure has and your requirements/priorities etc.
Azure has it's own task scheduling service - https://azure.microsoft.com/en-us/services/scheduler/
Scheduler Jobs are very simple to configure from Azure Portal. You can:
Make calls to http/https endpoints (which implicitly gives you multiple ways to solve your problems). Authentication can be done using basic, certificate or AzureAD OAuth Client credentials).
Send messages to Storage queue or Service Bus queue/topic which can then be processed appropriately by other processes.
If those Azure Scheduler capabilities aren't enough and you need something more involved, here is some guidance on the best practices documentation on background jobs - https://learn.microsoft.com/en-us/azure/architecture/best-practices/background-jobs#schedule-driven-triggers
Related
I have a Blazor app written in .NET6 which is responsible of transferring data from multiple tenant-databases to a single group-database. The transfer is being handled with links between databases and auto-generated sql queries. Each tenant-database to group-database transfer is a .NET thread.
The WebApp is hosted in Azure Web Services and is working good except some times where the Azure is doing some internal updates. For example the first problem was that Azure was restarting my application silently due to instance swapping, this was resolved with ARR Affinity switch. Then the application was restarting because of file server upgrades, for this I tried a custom property to run application in local cache. Now the app is still restarting while swapping from share content to cached content.
These Azure operations causes the WebApp to restart, as an effect the transfer threads are stopping and I need to start them again each time. This behavior is not acceptable for a such application. So I am looking other reliable ways to run the C#/SQL scripts.
I thought about Azure Web Jobs, but in this case I am not sure how can I autogenerate Web Jobs from the main application. But again, if the main app is triggering the Web Jobs and is being restarted, the .NET ticker will stop and will end up in the same result.
Any ideas?
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 have a confusion over differences between using app service alone and app service with web jobs.
I have a computation intense task (2-20 min) that must be triggered manually (user asks for it from time to time). Right now everything happens in one app service. I'm thinking to extract this heavy process to a webjob in another app service. This new app service will be empty (no api served) but host this web job, which I'll trigger from first app service.
I'm bothered that second app service will be empty.
Can I use second app service to do the work without using webjobs (just WebApi project)? Or I should stick to webjobs? What would be pros and cons of these two approaches?
In my opinion, we shouldn't compare the web api and web jobs. Because this two things is used for different environment.
The webjobs feature:
Web Jobs can be configured to be manually triggered or run on a
schedule.
Web Jobs can be configured to be Continuously running (aka running constantly, all the time)
Web Jobs can be setup to be Triggered based on events in other Azure Services, such as a new messaged added to a Storage Queue or Service Buss Queue or Topic
Web Jobs can be long running
Web Jobs can be short running
Web Jobs can be implemented in any language as either a command-line executable or script
Azure Web Jobs can be implemented to fill any background processing need.
So if you want to work with background processing and don't want to return the response to any other application. I suggest you could choose webjobs.
The web api is easy to build HTTP services for the customer to get the response.
So this is used to interact with others. So If you want to get the result and used in any other place. You could choose web api.
The web api feature:
Attribute Routing
CORS - Cross Origin Resource Sharing
OWIN (Open Web Interface for .NET) self hosting
Web API OData
...
All in all, if the computation will not interact with others(return the result to customer), I suggest you could choose web jobs.
What is the difference between WebJob and Cloud Service? I'm trying to get an overview over the two and by definition they seem to be able to accomplish the same goal? Maybe Cloud Service has more features?
Cloud Services (Web/Worker Role) will give you a full virtual machine (VM). Since you wanted to compare WebJobs with Cloud Service, I am assuming you're interested in Worker Role. Typically you would want to use a Worker Role to process background tasks. You could do the same with WebJobs as well. From what I understand, here are some of the key differences:
WebJobs are meant for one purpose only and that is processing jobs. You can do the same through Worker Role as well but since you're getting a full VM, you can do many more things with that (for example, hosting a node.js server).
If your objective is to run scheduled jobs, WebJobs make it super easy for you. You essentially take a console application, deploy it as a WebJob and then do the scheduling of job through portal. With WorkerRole, it's not that straight forward. Essentially you would be responsible for scheduling of jobs which you could either do it through in-built .Net libraries (System.Timer etc.) or use 3rd party scheduling libraries like Quartz.net.
If your application has dependency on some applications that you would need to install , you can't do through WebJobs. You could however install additional software in Worker Role through startup tasks.
I guess in the end both of them are PaaS offering but I consider WebJobs as true PaaS offering as you just come with your task and the platform takes care of scheduling and executing that task.
Can you run a standard Website and a Cloud Service on a single VM in Azure? I'm trying to figure out if I can run a website with a worker role for background jobs in a single Large VM instance.
Note: Large was chosen mainly for RAM requirements of the website, the background services should be fairly lightweight.
Edit: If they can't run on the same VM would having a Web Role and a Worker Role be the next best option? Would that require me to manage the VM?
No, the Windows Azure Web Sites do not coexist with a Cloud Service; however, you can certainly run a Cloud Service Web role that spins up other things in the background. You can do this by either including the code you wish to execute in the web site package and then spinning it up via a ProcessStart in the OnStart for the role entry point, or you can spin it up using a start up task (http://msdn.microsoft.com/en-us/library/windowsazure/hh127476.aspx).
Why have you chosen a Large to run it in? Is that because it needs the heavier power for the background work? If so, you could get the same cost from a Small and a Medium, or even less for two smalls. Don't forget that if your "worker process" is CPU intensive it could crush the machine and starve out the web processing.
I'm all for hosting multiple processes on the same VM, especially for workers, but I'd be skeptical of doing this with a web role involved if it sees a lot of traffic.
Another option if you aren't required to use the PaaS model is to use the new IaaS (Windows Azure Virtual Machines) and run both IIS and a Windows Service on it to serve as the background worker; however, doing this means you'll own and have to care for the VM for patching, etc.
Great news.. You can now do this!
Introducing Windows Azure Web Jobs
Azure Web Jobs make scheduled background tasks a breeze for Azure Web Sites.
So now you can have a single PaaS website and background services without even looking at Workers or Roles!