Skip to main content

Nexus vs Function as a Service

If you're reading the this documentation you might be thinking "well I can do this with scheduled Azure Functions and Azure Service Bus without any need for something like Nexus".

And you're right, you can do that and that setup is not bad at all. But Nexus has features that the Azure Function + Service Bus setup doesn't offer out of the box. Instead of seeing Nexus as a replacement for it you can see it as a complement. If you're already using Azure Functions you can have a function that executes Nexus jobs and functions since Nexus doesn't require you to run it as a continuous background service. Something like this:

public class NexusInvocation(IServiceScopeFactory scopeFactory)
{
    public async Task<string> RunAsync(CancellationToken cancellationToken)
    {
        await using var scope = scopeFactory.CreateAsyncScope();
        var jobs = scope.ServiceProvider.GetRequiredService<IJobExecutorService>();
        var functions = scope.ServiceProvider.GetRequiredService<INexusFunctionExecutorService>();

        var jobResults = await jobs.RunAllJobsPendingSinceLastCallAsync(cancellationToken);
        var functionResults = await functions.RunAllFunctionsPendingSinceLastCallAsync();
        return $"{jobResults.Count} Nexus jobs and {functionResults.Count} Nexus functions executed";
    }
}

Call this operation from the hosting platform's trigger and configure both JobsOptions.UseBackgroundService and NexusFunctionsOptions.UseBackgroundService to false. See hosting for registration. The operation creates a scope because both executors are scoped.

For periodic hosts, persist required job starts through IJobMetaDataRepository.ScheduleExtraRunAsync() rather than relying on immediate parameterless IJobStartRequester events; those events are handled only by continuous job loops. Readiness-driven queue jobs are reconciled when the job executor is invoked. Do not register distributed queue processors in a host that stops between invocations.

You can invoke this operation as often as you like and Nexus will make sure to call the jobs and functions that should run. If you schedule the Azure function to run every five minutes and you have Nexus jobs that are scheduled every minute they will only run every five minutes. You should schedule the Azure function to run as often as you want your most often running Nexus job to run.

Cost efficiency

Running Nexus as a scheduled Azure function can be a cost efficient way of running functions and background jobs in test environments since it doesn't require a server that's always running.

Benefits with Nexus jobs​

When everything is running smoothly Azure functions and Nexus are quite equal. But Nexus starts to shine when things aren't. When you get a call from a business stakeholder and she tells you to stop the order export you can quickly go in to the admin UI and disable the job or even guide the stakeholder how to do it herself. Empowering non-developers with regards to background jobs and queues is one of Nexus strengths. With health status and job logs visible in the admin UI it's possible for almost anyone to get at least a basic understanding of why things are failing and help out in troubleshooting.

Another big benefit of Nexus is how easy it makes local development. You're not dependant on accessing cloud functionality to build jobs and with SQLite you don't even need a database server. Minimizing the differences between how code runs locally vs in production is very valuable.

Benefits with Nexus functions​

Many of the benefits with Nexus jobs applies to Nexus functions as well but they deserve a special mention since the name can make them seem to do the same thing as Azure Functions. The big difference is how easy it is to pass arguments in a type safe way to a Nexus function compared to an Azure function.

Nexus queues vs Azure Service Bus queues​

Azure Service Bus queues are great and have a lot of functionality. One of the strength of Azure Service Bus queues is that it can handle a very large number of messages. For some workloads raw broker throughput is the main requirement; for others inspection of individual messages and controlled retries matter more. Instead you want more insight into each and every message for these processes.

A trade-off in being able to handle that kind of volume is that Azure doesn't offer the same kind of introspection into queues as Nexus does. You can read, filter, paginate and update Nexus queues either through the UI, the API or in your favorite SQL management application. You can use the built in JSON functionality of your database to find messages by properties in the JSON message.

Since Nexus makes a different trade-off than Azure it lets Nexus queues offer features that aren't possible with Azure queues. Such as virtual queues, idempotent messages and to store processed messages. Storing processed messages lets you build sophisticated change tracking since you get access to the previous version of the message to let you diff them.

If you want to you can also use the CommerceMind.Nexus.Azure NuGet package to read from an Azure queue and add them to a Nexus queue.

For high-throughput workloads, Nexus can also process directly from external pending storage, including Azure Service Bus topics. Distributed processors let every continuously running instance contribute workers. These options keep Nexus's queue controls while changing where pending messages live and how processing scales.