Recently Windows Azure announced a new Scheduler Service in preview. In this blog post, we will talk about some basic stuff to get you started. In the subsequent posts, we will drill down into more details.
What
Let’s first talk about what exactly is this service. As the name suggests, this service allows you to schedule certain tasks which you wish to do on a repeated basis and let Windows Azure take care of scheduler part of that task execution.
For example, you may want to ping your website every minute to see if it is working properly (like checking for HTTP Status 200). You could use this service for that purpose.
Please do realize that it’s a platform service or in other words it provides a scalable platform for task scheduling. The service will not execute the task itself. That’s something you would need to do on your own.
If we take the above example of pinging website, what you can instruct this service to do is ping the website every minute and it will ping the website at the time/interval specified by you and keep the result in job history.
Activating
Currently this service is in “Preview” mode thus you would need to activate this service first before you can use it. To activate this service, go to account management portal (https://account.windowsazure.com) and after logging in, click on “preview features” tab and then clicking on “try it now” button next to “Windows Azure Scheduler” to activate this service in your subscription.
That’s pretty much it! Now you’re ready to use this service.
How to Use?
At the time of writing this blog, Windows Azure Portal does not expose any user interface to manage this service. However there’s a REST API which exposes this functionality. You can write an application which consumes this REST API to interact with this service. If you’re a .Net programmer, there is a .Net SDK over the REST API available for you. This is available as a Nuget package which you can get from here: http://www.nuget.org/packages/Microsoft.WindowsAzure.Management.Scheduler/0.9.0-preview.
Sandrino Di Mattia (http://fabriccontroller.net) has written an excellent blog post on using this .Net SDK. I would strongly recommended reading his post about this: http://fabriccontroller.net/blog/posts/a-complete-overview-to-get-started-with-the-windows-azure-scheduler/.
We will focus on REST API in this series of blog posts.
Concepts
Now let’s talk about some concepts associated with this service. In a nutshell, there are three things you would need to understand:
Cloud Service
A cloud service is a top level entity in this service. You would need to create a cloud service first before you can create a job. Few things about cloud service:
- Consider a cloud service as an application in which many of your job will reside and execute. A subscription can have many cloud services.
- A cloud service is data center specific i.e. when you create a cloud service, it resides in a particular data center. If you want your jobs to be performed from many data centers, you would need to create separate cloud services in each data center.
Job Collection
A job collection is the next level in entity hierarchy. This is where you group similar jobs together in a cloud service. Few things about job collection:
- A job collection is responsible for maintaining settings, quotas, and thresholds which are shared by all jobs in that collection.
- Since a job collection is a child entity of a cloud service, it is again data center specific. For a job to be performed from many data centers, you would need to create separate job collections in each cloud service specific to that particular data center.
Job
A job is the actual unit of execution. This is what gets executed at the time specified by you. Few things about jobs:
- At the time of writing this blog, this service allows two kinds of jobs – 1) Invoking a web endpoint over http/https and 2) post a message to a queue.
- Do realize that the service is simply invoking a web endpoint or posting a message to a queue and returns back a result. What you want to do with the result is entirely up to you. For example, you have a log pruning task which you want to execute once every day. You could create a job which will put a message in a Windows Azure Storage Queue of your choice every day. What you do with that message would be entirely up to you.
Job History
As the name suggests, a job history contains the execution history of a job. It contains success vs. failure, as well as any response details.
Alternatives
Now let’s talk about some of the other alternatives available to you when it comes to executing scheduled jobs:
Aditi Task Scheduler
Aditi has a task scheduler service which is very similar in the functionality offered by this service (http://www.aditicloud.com/). Aditi’s service also allows you to ping web endpoints as well as post messages in a queue. Now the question is which one you should use :).
A few things that go in favor of using Aditi’s service are:
- Aditi’s service has been running in production whereas Windows Azure Scheduler Service is in preview so if you have production workloads where you would need this kind of service, you may want to consider Aditi’s service. Having said this, if you have been using Windows Azure Mobile Service’s Scheduling functionality, it has been backed by this service only. So if you’re somewhat concerned about it being in preview, Don’t :).
At the time of writing, Windows Azure Scheduler Service has lesser features than Aditi’s Service. For example, Aditi’s service allows you to POST data to web endpoints. Also it supports basic authentication. These two features are not there in Windows Azure Scheduling Service as of today.Please see Update below.
A few things that go in favor of Windows Azure Scheduler Service are:
- It is integral part of Windows Azure offering.
- Aditi’s service is only offered through Windows Azure Store. Since Windows Azure Store is not available in all countries, you may not be able to avail this service (I know, I’m not) from Aditi. Windows Azure Scheduler Service does not have this restriction.
UPDATE:
Based on the feedback I received, Windows Azure Scheduler Service supports all HTTP Methods (GET, PUT, POST, DELETE, HEAD). Furthermore it also supports basic authentication as well.
Roll Out Your Own
Other alternative would be roll out your own scheduler. I wrote a blog post sometime back which talked about this. You can read the post here: https://gauravmantri.com/2013/01/23/building-a-simple-task-scheduler-in-windows-azure/. If you’re going down this route, my recommendation would be not to implement your own timers but use something like Quartz.net.
REST API
Let’s talk briefly about the REST API to manage scheduler service. We will deal with in more detail in subsequent posts. You can learn more details about the REST API here: http://msdn.microsoft.com/en-us/library/windowsazure/dn479785.aspx.
Authentication
To authenticate your REST API calls to the manage scheduler service, you would use the same logic as you do today with authenticating Service Management API requests i.e. authenticate your requests using X509 Certificate. To learn more about authenticating Service Management API requests, click here: http://msdn.microsoft.com/en-us/library/windowsazure/ee460782.aspx.
Things you could do
At the time of writing of this blog post, here are the few things you could do with REST API:
- Create/Delete/Get/List Cloud Services
- Create/Update/Delete/Get/List Job Collections
- Create/Update/Delete/Get/List Jobs
We will take a deeper look at these operation in next post.
Summary
I’m pretty excited about the availability of this service. In fact, I could think (actually we’re thinking about) of a lot of scenarios where this service can be put to practical use. I hope you have found this post useful. Are you planning on using this service? If you please provide comments and let me and other readers know how you are planning on using this service.
This was pretty simple post with no code to show. In the next post, it will be all about code. I promise :).
So long and keep coding!!!
