Thread by @Nick_Craver

This is a good addition to .NET - the Stack Overflow scheduler is based on IHostedService, and we have a lot of other plans for it too.

https://twitter.com/davidfowl/status/1044466627075428352

Some examples of queues we have at Stack:
- The aggregator, which puts stuff in network-level tables for things like reputation in your top bar.
- Account queues, for merging/deleting users and such.
- GDPR request completion
- Elasticsearch indexing
- Related question rebuilds

We've moved them to a common "service" type implementation with shared logging, locking, and status reporting infrastructure. They're currently async/await Task.Delay style node competition services we'll move to IHostedService in the move to #AspNetCore.

When you consider our deployment scenarios, options this enables become very appealing.

Scaling up or out in prod? Separate scheduler instance that does a lot of work.

Running local or Enterprise with a few sites? Just fire up the scheduler IHostedService in-process on startup.

When we built the new Stack Overflow scheduler, it's in 3 projects: SDK lib (a .nupkg, minimal classes needed to interface with it as an API), the IHostedService bits (also a .nupkg), and a very thin #AspNetCore site that runs the middle package on startup. That's all it does.

So now, we can make things that can run elsewhere as a dedicated/beefy service, or do the same work in-process for smaller deployments with simpler infrastructure. Trivially. It's so pluggable.

We love it. Can't wait to finish this move...so many wins in .NET Core.

Been asked a few times: will we open source the scheduler? Yeah, maybe. It's really not specific to us at all. It just supports a multi-tenant infrastructure especially well. It'll probably end up on GitHub a bit later when we have the time and fully vet all the combos here.