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.
Related
I have an ASP.NET core 3.1 based web api ready to deploy to Azure for production use. For test / development, I have been deploying it to a traditional app service on Azure which I believe is a shared Windows VM under the hood. I have been on F1 tier and it suits my needs for test and dev.
But for production, even the cheapest plan costs me $93.44 per month which I would like to avoid if I can.
In order to lower the cost, I have decided to containerize my app and deploy it using "web app for containers" or "azure container instances". My question is, based on your experience, which method will give me reasonable production-scale performance while minimize my monthly cost? Or would containerize my app save me any money at all?
Please note that I have evaluated Azure Functions and decided it is not what I would like to use.
For your requirements, first of all, you need to know that the Azure Container Instance benefits for its quick start and running. See this:
Azure Container Instances is a great solution for any scenario that
can operate in isolated containers, including simple applications,
task automation, and build jobs.
It's good for the simple application, but not good for scenarios where you need full container orchestration, including service discovery across multiple containers, automatic scaling, and coordinated application upgrades. And I think it's also not stable for the production use, it's more appropriate for the test.
And the Azure App Service is cost according to the service plan, the service plan billed on a per second basis. You can plan the use with time as you need and the App Service has more features than Container Instance. Or if you do not satisfied with App Service, maybe you can take a look at the Azure Kubernetes Service, it has more control and feature then the Container Instance.
As of beginning of 2022 looks like Container Instances and Web Apps for containers will be the same ~32eur which is a bit better than the app service ~50eur.
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
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.
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.
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!