The guide does not provide definitive answers for all situations and each option involves trade-offs. Particularly in cloud scenarios, there are several options and the best solution depends on the requirements of individual scenarios. If it is unclear what the best choice is, or there are specific constraints, contact Particular Software for advice.
NServiceBus endpoints can be hosted in any .NET process. This guidance groups the hosting options into:
For on-premises hosting, endpoints are typically hosted in background processes running on servers, which are usually virtual machines. An endpoint can also be hosted in an interactive application with a user interface, but this guide focuses on server scenarios.
In Windows, a Windows Service is the most common way to host an NServiceBus endpoint.
Windows Services run in the background, can immediately start when Windows is started, can be paused and restarted, and support recoverability options.
See Windows Service Hosting for details.
In Windows, IIS is a reliable host for web-based applications. An NServiceBus endpoint can be hosted in any .NET web application, including one running in IIS. However, the purpose of IIS is HTTP request-based hosting. That means IIS will automatically shut down any web application that has not received a request for some time.
This restricts IIS as a choice for hosting NServiceBus endpoints to two specific scenarios:
- Send-only endpoints, which can send but don't receive messages, and therefore don't need to initialize any receiving infrastructure. Messages are sent during the handling of incoming HTTP requests or after user input in an interactive application.
- Web applications which provide near real-time feedback using queues for asynchronous and reliable communication.
See Web Application Hosting for details.
In Linux, a background process is typically controlled by a system service controller. One of the most commonly-used is systemd. These controllers can be configured to start and stop any executable, typically a console app, as a background process when the operating system starts and shuts down, as well as more complex configurations.
One difference in hosting NServiceBus endpoints using containers, compared to a regular host OS, is that applications are isolated from the host, and other containers. This has security as well as portability benefits. It is easy to move containers from development to test and production.
See Docker Container Host for details on hosting endpoints in Docker.
Azure offers a variety of solutions which can host NServiceBus endpoints. Unfortunately, none of them are specifically designed to run continuous background processes, similar to Windows Services. So it can be challenging to choose the best hosting options for NServiceBus endpoints. For assistance, contact Particular Software.
The primary options for hosting NServiceBus endpoints are:
Within AppServices, WebJobs can host background processes. This is the recommended solution for hosting NServiceBus endpoints.
Azure Functions can be used to run short-lived NServiceBus endpoints triggered by Azure Service Bus messages. When a message triggers a function, an NServiceBus endpoint can be started to handle the message.
See Azure Functions with Azure Service Bus for more details.
Service Fabric works on top of Virtual Machine Scale Sets to provide clustered, stateful services. If dynamic scaling and clustering is a requirement, Service Fabric can be a good option to host NServiceBus endpoints.
Although there is a comparison chart that compares Amazon Web Services (AWS) to Microsoft Azure, AWS does not provide any comparable alternatives for hosting background processes. That leaves the following options for Amazon Web Services:
AWS virtual machines provide the same options as those described in on-premises.
AWS containers provide the same options as those described in containers section.
AWS Mesh is comparable to Azure Service Fabric.