This document provides guidance for deciding how to host NServiceBus endpoints.
The guide does not provide definitive answers for all situations, and each option involves trade-offs. Several options exist, particularly in cloud scenarios, 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:
On-premises
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.
Windows Services
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.
Internet Information Services (IIS)
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, IIS's purpose 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 while handling 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.
Linux background processes
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.
Containers
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 and 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.
Microsoft Azure
Azure offers various solutions for hosting NServiceBus endpoints. The best option depends on the requirements of each scenario. For assistance, contact Particular Software.
The primary options for hosting NServiceBus endpoints are:
App Service
Within App Service, WebJobs can host background processes, making them suitable for hosting NServiceBus endpoints.
Containers
NServiceBus endpoints can be deployed to Azure container services such as:
See Docker Container Host for details on hosting endpoints in Docker containers.
Azure Functions
Azure Functions can run NServiceBus endpoints in a serverless and dynamically scaled environment. See Azure Functions with Azure Service Bus for more details.
Service Fabric
Service Fabric works on top of Virtual Machine Scale Sets to provide clustered, stateful services. If dynamic scaling and clustering are required, Service Fabric can be a good option for hosting NServiceBus endpoints.
Amazon Web Services
AWS offers various solutions for hosting NServiceBus endpoints. The primary options are:
AWS Lambda
AWS Lambda can run NServiceBus endpoints in a serverless and dynamically scaled environment. See AWS Lambda with SQS for more details.
Virtual Machines
AWS EC2 virtual machines provide the same options as those described in on-premises.
Containers
NServiceBus endpoints can be deployed to AWS container orchestration services such as:
See Docker Container Host for details on hosting endpoints in Docker containers.