Our team are planning on using the load balancing mechanism that comes with the newer Umbraco versions (we just upgraded to 17).
Our dream setup is to have one instance for the backoffice with nothing else. Then we want one or two instances, only running the Delivery API, to serve content you our websites.
I wan thinking on using the SchedulingPublisher and Subscriber (serverroles) to make this possible. But i wanted to be sure on one thing.
It’s is fine to the same project but determine what instance does what, based purely on environment variables?
We haven’t tried it yet, but we just wanted some “aha” and know-how before we start setting up everything.
Yep… At least the serverroles by environment bit.. haven’t used the deliveryapi against subscribers myself.
using Microsoft.AspNetCore.Hosting;
using Umbraco.Cms.Core.Composing;
using Umbraco.Cms.Core.DependencyInjection;
using Umbraco.Cms.Core.Sync;
using Umbraco.Cms.Infrastructure.DependencyInjection;
namespace www.Extensions.LoadBalancing
{
public class ServerRegistrar : IServerRoleAccessor
{
private readonly IWebHostEnvironment _env;
public ServerRegistrar(IWebHostEnvironment env)
{
_env = env;
}
public ServerRole CurrentServerRole
{
get
{
return _env.EnvironmentName.ToLower() switch
{
string n when n.EndsWith("api") => ServerRole.SchedulingPublisher,
"development" => ServerRole.Single,
_ => ServerRole.Subscriber,
};
}
}
}
public class RegisterServerRegistrar : IComposer
{
public void Compose(IUmbracoBuilder builder) => builder.SetServerRegistrar<ServerRegistrar>();
}
}
Yes, this is pretty normal for load balanced sites, and is not something new for v17. You’ve been able to do the kind of load-balancing in those docs for a long time.
What’s new in v17 is that you can Load Balance the backoffice:
So, in v17 it isn’t strictly necessary to have separate publisher and subscribers - you can just set them all to be publishers and scale horizontally with as many instances as you need - with the option to scale to a single instance.
From version 17, it’s possible to load balance the backoffice. This means there’s no need to differentiate between backoffice servers and front-end servers. However, this requires some additional configuration steps.
so not quite as simple as you can just set them all to be publishers and scale horizontally with as many instances as you need ??
Surely there is some benefit to publisher vs subscriber though?? Otherwise the serverrole is redundant and could be removed or is that slated for a later release?
Not quite, but it’s all there in the doc and pretty straightforward to implement.
I raised this with HQ, as SchedulingPublisher doesn’t make sense in this context and should be redundant. My understanding is that eventually it will go away but I suspect that will be some time away.
HQ don’t like binary breaking changes, even when behaviour is changing that should break the binary! As such, as of v17 SchedulingPublisher doesn’t actually mean what it used to mean - and if you are using that in your code to target a single instance, that will no longer be the case if someone is “load-balancing” the backoffice.
Not as far as I can see.
HQ chose to keep the current single-backoffice/multiple “client” approach as the happy path. Hence the other steps to jump through.
I’d much prefer if scaling the backoffice was supported OOtB/by default and we could just throw Umbraco at docker or Azure Web Apps and scale without caring, but alas, that’s not the choice that was made. Though it’s not a lot of work to ship the code/config as a package - we may end up doing this internally.
As an aside, I hate so much that we call this “load-balancing”, and treat it as some advanced edge-case. Scalability is a solved problem for modern web apps and should Just Work. All the code/configuration necessary should be baked right into Umbraco by default - scaling and load balancing should only ever need to be an infrastructure concern.
maybe scheduling publisher could become a proper this is the only way to access the backoffice, and subscribers can only access the frontend.
and single if you don’t want to spilt concerns?
But I would still think there should be some configuration that would make subscribers more performant, or some other metric, knowing that we don’t need a backoffice.. perhaps even removing a dependency on the database.. and continuing to run against caches?
A bit like i guess a headless setup could provide too???
i have a feeling some clients would be a little reticent to have any and all boxes being open to public access with admin too.. Though multifactor, and external login provider of choice should be enough??
