Hybrid Broadcast Infrastructure Forces Monitoring to Follow the Workflow

Cloud-native and containerized technology was one of the clearest trends at IBC 2026, yet few broadcasters are abandoning on-premises infrastructure. Their environments are increasingly mixed, according to Anupama Anantharaman, Vice President of Product Management at Interra Systems, and that mixture is forcing a rethink of where video monitoring actually sits.

Some applications remain on dedicated hardware. Others run as virtual machines or containers, and certain workloads move into public cloud or spin up temporarily for specific events. Each model has its place.

• Bare metal suits workloads that depend on dedicated hardware, deterministic latency or high-density I/O.
• Virtual machines let established applications run on shared infrastructure with little redesign.
• Containers, managed through orchestration, support rapid deployment and scaling.
• Public cloud supplies capacity on demand for temporary and event-driven workloads.

The question Anantharaman poses is whether monitoring architecture should follow the workload rather than dictate where that workload has to run. Her answer, laid out in an industry analysis, is that it should — and that the consequences of getting placement wrong compound quietly until a major live event exposes them.

Where should probes sit?

Probe placement is one of the most consequential decisions in a hybrid design. In low-latency contribution and live production, probes belong as close as possible to the point where the stream is fully visible, so that frozen video, audio silence or missing captions surface immediately.

A probe placed in the cloud can add delay from network conditions and buffering, though the extent depends on the workflow. In an all-cloud architecture, contribution feeds and monitoring data sharing a capacity-constrained link can put both QoS and QoE at risk.

Capacity planning follows from the number of streams, their bitrates, codec complexity and the depth of decoding required. A system that performs well during routine operations may struggle during a major live event, when stream counts and processing demand peak. Continuously decoding and analyzing hundreds of streams demands significant computing resources, and placement compounds the problem: when monitoring shares infrastructure with production services, competition for resources can compromise both fault detection and the services being monitored.

Dedicated servers or separately provisioned container pools help isolate workloads. Monitoring should be sized for peak demand, whether that capacity is permanent or event-driven, since average utilization understates what a major event requires.

Why isolation protects visibility

Resilience is the second argument for separation. Monitoring depends on independence from the systems it observes. When a probe runs on the same server, network segment or cloud region as the workload, a single outage can disrupt the service and leave operators unable to see the failure. Separate hardware, another availability zone or a different provider preserves visibility during the outage.

Cost shapes placement too. Transporting full-bitrate streams from the cloud to a central operations center can incur substantial, recurring transfer charges. Analyzing streams where they reside and forwarding only alerts, metadata and low-resolution thumbnails can significantly reduce that traffic.

No single location wins on latency, performance, resilience and cost at once. The recommended pattern is distributed: lightweight analysis close to each workload, with results consolidated into a unified operational view.

What does consistency across environments require?

Moving workloads between environments should never break the ability to track performance over time. Operators need to see how a service behaved before a move, during the transition and after it settles. That requires the same measurements everywhere — packet-level analysis within the managed network, OTT manifest checks, and player data such as rebuffering — while recognizing each observation point serves a different purpose.

Consistency begins with shared definitions. Black frames, freezes, silence, out-of-range loudness and caption gaps should carry the same test parameters and thresholds in every deployment, and alerts should follow the same severity levels and escalation paths. Open APIs then connect monitoring to orchestration, ticketing and analytics, so teams automate workflows rather than moving information between tools by hand. Correlation across the chain lets operators trace an output problem back through ingest, encoding and distribution, even when those stages run in separate environments.

Anantharaman, a Silicon Valley-based executive with more than two decades in video compression, transmission and OTT streaming, frames the goal as infrastructure independence: deploying quality and compliance monitoring wherever the content resides, managed from one place.

Over the next three to five years, her advice to engineering leaders is to make monitoring consistency a prerequisite for infrastructure expansion, verifying that any proposed environment can support monitoring requirements before workloads move into it.