Hosting Model

Runly is a platform for running background jobs. It works by allowing you to run your background jobs out-of-process from your main application.

In-process means the background job runs in the same process as the application using it. Out-of-process means the job runs in a different process than the one that started the job. The two processes could be running on the same machine or on different machines, but the main point is the processes cannot call methods in other processes directly.

How it Works

Running jobs out-of-process differs from other approaches such as .NET’s IHostedService model or Node.js’s worker_threads which will run your background tasks on separate threads within your application’s process.

The main drawback of running your background jobs in-process revolves around the life of your job being tied to the life of your application. If your application crashes or is force-closed, all of your background jobs will die with it. IHostedService tries to alleviate some of this risk by providing a StartAsync and StopAsync for each background service. When your application is shutting down normally, it will wait (a certain amount of time) for all background services to finish StopAsync. This will guarantee your background service is given an opportunity to finish if the application shuts down gracefully.

If you need a guarantee that your background job will finish, you need to move to an out-of-process model. Runly background jobs are run on worker nodes that can be run the on same machine that your application is running or on a completely different machine or on multiple machines in the cloud. All of your Runly background jobs run via of one of the nodes connected to your organization.

By decoupling your application from your background job, the job is allowed to run to completion regardless of what happens in your application. The worker node and the job host are built to be fault tolerant, working together to ensure the error detail is captured and reported back to you when a fault does occur. Even if a job fails, it can be picked up where it left off and is more resilient to failures out-of-the-box than an in-process background service.

Deployment

A big drawback to hosting your background jobs out-of-process from your application is that you now have to deal with deploying that separate background job application separate from your main application.

Runly alleviates this pain by making it simple and easy to integrate job deployment with your current workflows. To deploy a job application, all you need to do is pack and publish the application as a NuGet or npm package and push it to your organization’s feed. See how this is done in an example GitHub Action workflow.

Once the package is pushed to your organization on Runly, it can be run on any node in your infrastructure. Once a job is enqueued to run on a node within your organization, the worker node takes care of retrieving the package for that job and running it on that machine. The worker node takes care of the heavy lifting by deploying your job application to machines where it needs to run.

Utilizing Runly, you can have the benefits of out-of-process background jobs without the headaches of deployment.

Next Steps

Learn more about how nodes & clusters work with your infrastructure.
Read more about deploying jobs via packages.