What "always-on" actually means for distributed creative work.

The phrase gets used a lot. Always-on. Always available. Always hot. Active-active. High-availability. It all sounds like infrastructure language. In practice, it points to something more specific: a different assumption about how a distributed workspace is supposed to behave.

The old assumption was that content moves between places. You transfer a file from one location to another. You schedule it, it runs, it arrives. That model made sense when work moved sequentially - one facility handing off to the next. The infrastructure was built around it. Point-to-point transfer tools. Overnight windows. Manual triggers. A coordinator who checks the job completed before the next team starts.

That model still exists. But it’s not what distributed creative work actually looks like now.

‍

The shift that changed the requirement

A facility delivering a long-form drama isn’t moving content from A to B. Editorial, VFX, colour, and finishing are running concurrently, across multiple sites, often in different time zones. Assets aren’t handed over and done. They’re being worked on simultaneously, by multiple contributors, across all of those environments at once.

Changes made in one place need to be visible everywhere else - automatically, without anyone scheduling a transfer or waiting for a window.

That’s not a faster version of the old model. It’s structurally different. And tools built for delivery, however fast, don’t stretch cleanly to support it. You can schedule more frequent transfers. You can layer cloud tools on top. A lot of facilities do exactly that. But you end up managing the workspace rather than relying on it.

‍

What “always-on” actually requires

For a shared workspace to be genuinely always-on, a few specific things have to hold at the same time.

• Files need to be accessible when an artist opens the tool, not after a staging delay.
• Only the changed parts of a file should move across the network - not the whole thing - so a small update to a large media asset propagates in seconds.
• Changes need to reach every connected site automatically.
• And when connectivity drops, work should continue uninterrupted, because the files are physically there, not streamed from a cloud filesystem that goes dark when the connection does.

‍

That last point is where cloud-first tools tend to break down. They work well when artists are close to the storage and the connection is stable. When distance increases, or bandwidth gets squeezed, performance degrades. And because the data lives inside a proprietary filesystem the operator doesn’t control, moving it elsewhere is a project in itself.

What you need instead is a workspace where data stays local at every site, continuously in sync, on the storage you already own. If connectivity drops, the files are still there. When it comes back, sync resumes from where it stopped - no intervention, no data loss, no re-transfer of what already moved.

‍

Why it matters beyond the technical argument

The operational case is as important as the technical one. A workspace that requires active management has a cost that doesn’t show up on a hardware invoice. It shows up in the hours spent monitoring jobs, reconciling versions, and fielding calls when something degrades at the wrong moment in a production schedule.

A workspace that runs underneath everything else - self-healing, continuous, transparent to the artists using it - returns that time to the people doing the work. Your team doesn’t interact with it. They don’t see it. They just open the tool and get on with the job.

‍

The question worth asking

Always-on isn’t a feature. It’s an infrastructure assumption. The question is whether yours holds up under the actual conditions of a live production - not just when everything is running smoothly, but when a connection drops, a deadline compresses, and two teams are working on the same assets at the same time.

If any of this resonated, get in touch. Resilio Active Everywhere on Sohonet is built for exactly these conditions.

‍