0

I am developing a greenfield project which has two requirements.

  • To be ran in the cloud (Azure).
  • To be ran on a self hosted Windows Server installation.

This project is broken into 3 main parts.

  1. A collection of clients.
  2. A RESTful server.
  3. Persistent Storage.

For this question the clients are irrelevant, the RESTful server is built with ASP.NET WebApi (satisfying the requirements above) and the persistent storage is Azure Tables in case of the cloud or RavenDb when self hosted. And so to the question.

What is the best mechanism for scheduling jobs in this architecture that satisfies both requirements listed above.

I have a concept of jobs which are ran by querying the RESTful server and asking it to do a scheduled time check on any active jobs so the service really only needs to make a very simple rest query to start the process.

All the jobs and the logic to run them (They are templates) is on the server so no logic is required by the service.

Ultimately the best response would be some sort of ticker service that asks the service to preform the check. If I could build this directly into the ASP.NET WebApi server I would be even happier. It is a new tech to use so please excuse any glaring oversights I may have missed that would resolve this question.

deanvmc
  • 5,957
  • 6
  • 38
  • 68
  • 1
    Have you looked at Quartz.net (http://www.quartz-scheduler.net/) for scheduling tasks? – Gaurav Mantri Oct 19 '12 at 03:14
  • I haven't looked at particular libs just yet specifically because I am unsure of what I need from an architectural point of view. I am also wary of adding a lib dependency for what I need which is essentially a ticker of some sort to run a request. – deanvmc Oct 19 '12 at 08:04
  • Quartz is stable with large following - but this means you need implement everything yourself. – Swab.Jat Jan 25 '14 at 05:04

1 Answers1

1

One approach would be to write a very simple 'scheduler service' (similar in principle to quartz scheduler mentioned in the OP comments) written in [insert favourite .Net language here].

This service can be as simple or as complex as you wish; at the lower end it could simply operate a timer that at set intervals would invoke the REST API to trigger your process

The service itself could be written as a class library which can then be hosted within a Windows Service when deployed on a Windows Server installation; or, hosted within an Azure Worker Role when deployed to the cloud. When deployed in an Azure Worker Role the scheduler could easily run within an XS instance (1GHz CPU, 768MB RAM, 20GB Storage) at minimal cost - $14.40 per month at current prices.

This approach allows the same code-base to be used in both solutions (simply reference the class library project) and can be independently unit-tested.

Taking this approach one step further, you could automagically load the class library assembly at runtime, making future deployment and upgrades extremely easy.

Nick Heppleston
  • 1,973
  • 11
  • 18
  • Ah, so that seems easy enough, yes essentially the service just needs to tick every 5 to 10 mins so I think this idea fits nicely, I didn't think it was that cheap to run a service in azure but based on those costs rounded for a year it is acceptable. Cheers! – deanvmc Oct 19 '12 at 09:44
  • Hang on, I just reread the last part, I don't even need a separate worker role, since I am using a web role for the webapi in the case of a cloud deployment I can just have the service spin up beside it. You sir are a legend! – deanvmc Oct 19 '12 at 09:58
  • 3
    @deanvmc - just remember: If you run the scheduler service alongside your web role, you need to ensure that only one instance of the scheduler is running (same problem with separate role, actually). The issue comes about when you increase instance count of your web role (REST API, in your case) or worker role (dedicated to scheduling, per Nick's suggestion). In either case: you should only run one copy of scheduler. You can use a blob-lease as a mutex, as one way to achieve this. – David Makogon Oct 19 '12 at 12:44
  • Cheers @DavidMakogon I was just working through this issue on paper as the main reason for the cloud deployment was scale! – deanvmc Oct 19 '12 at 13:52