0

We have the requirement to implement some fire and forget long running tasks that fit perfectly into windows services (remote data acquisition and processing, etc) but the requirement is to deploy them into hosts without remote administration rights.

We are thinking on the possibility of hosting these tasks as background tasks that run on the IIS and that are stored into the Application object (or some other global variable-like approach).

Issues with this solution that I can think ok:

  1. Scalability: if there is more than one server you will have more than one task and this is not allowed. Workaround: to implement a control mechanism so there is only one running at the same time.
  2. Shortages: the service will stop everytime we deploy a new version of the application. Workaround: to implement the service into a separate application so it is only restarted when there is a new version of the service.

Is there something else you can think of that could pose a problem to this approach?

Improve this question
2
  • I don't understand issue #1. If you have more than one machine and start that service on every machine you would get that task more than once as well, so what has this to do with using a web server?
    – Doc Brown
    Mar 5, 2018 at 6:36
  • @DocBrown: the requirement is to have just one service running no matter how many webservers are started. Turns out that implementing the workaround of the 2nd point the 1st one gets solved as well as we won't spawn new servers for the new application. Any other problems that someone can foresee?
    – Ignacio Soler Garcia
    Mar 5, 2018 at 7:34

1 Answer 1

Reset to default
2

What you describe is simply a Microservice architecture. By making your long running task a web service on its own, separated from the main application, problem #2 is solved - and that is not a "workaround", as you called it, it is an architectural style.

Moreover, by separating the main application from the web service, the number of application instances you spin up is independent from the number of tasks running in that web service. Keeping that number of tasks to 1 at maximum then should be simple, as long as there are not multiple deployed instances of the web service. This should be a solution for #1. I guess that it what you already found out by yourself, according to your comment.

Improve this answer
3
  • This is exactly what I would have recommended. You need the flexibility to spin up new instances of the web application to deal with load. Keeping the long running service as a separate microservice allows it to have it's own deployment schedule.
    – Berin Loritsch
    Mar 5, 2018 at 14:31
  • Well, the main point of the question is that it is not a service in itself. There is no public interface, all it does is to gather data and to store it into a kind of database as soon at it gets deployed. Does this still fit into a microservice?
    – Ignacio Soler Garcia
    Mar 5, 2018 at 21:27
  • @IgnacioSolerGarcia: sure it is a (micro)service in itself, and nowhere is written a microservice needs a public interface. Quite the opposite, by dividing up an application into several smaller services, I would expect most of the communication between those service be internal to the system.
    – Doc Brown
    Mar 5, 2018 at 22:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.