Advancing the Creation, Production and Distribution
of Sports Content

Cloud

Cloud-native media has arrived – but operating it effectively is the real challenge

The media industry is no longer debating whether it will move towards cloud-native architectures. That transition is already underway. What remains far less certain is whether the industry is developing the operational capability required to run cloud-native media platforms reliably, economically, and at scale.

A useful way to examine this gap is through the lens of the EBU Dynamic Media Facility (DMF) initiative, using it as a starting point to examine a broader challenge facing the industry as it moves towards cloud-native media platforms. DMF is not a speculative vision or a vendor roadmap. It is a concrete attempt to describe how media facilities can operate as distributed, software-defined systems built around interoperable services rather than tightly coupled infrastructure.

In doing so, DMF makes two things clear. First, the architectural direction of travel for media is increasingly aligned with modern software platforms. Second, the operational implications of that shift are still widely underestimated.

This article focuses deliberately on capability rather than technology choices. It does not attempt to prescribe specific platforms or tools, but instead examines the operational assumptions that sit behind initiatives such as DMF, TAMS and LPX.

DMF as a marker of intent

DMF reframes the media facility away from racks of integrated hardware and towards a composition of services. Media processing, timing, control, metadata and exchange are treated as software components that can be deployed across on-premises environments, private clouds and public cloud infrastructure. Facilities become dynamic systems that evolve continuously rather than static installations refreshed on multi-year cycles.

This framing aligns closely with other industry initiatives such as Time Addressable Media Stores and the DPP Live Production eXchange (LPX). Together, these efforts point towards shared exchange layers, time-aware media objects and federated operation across organisational boundaries.

Collectively, they describe media systems that behave far more like large-scale software platforms than traditional broadcast plants. The architectural logic is compelling. The operational reality is harder.

From engineered certainty to managed uncertainty

Broadcast engineering has historically been built around deterministic systems. Signal paths are explicit, failure modes are well understood, and behaviour is predictable. Reliability is achieved through careful design, redundancy and tightly controlled integration, often delivered by vendors who own large parts of the system end to end.

Cloud-native platforms invert many of these assumptions. Modern media services are distributed by default, composed of independently scaled components, and expected to continue operating in the presence of partial failure. Capacity is elastic rather than fixed, and system behaviour emerges from the interaction of services rather than from a single linear chain.

Read more Inside TAMS: How Time-Addressable Media Stores could redefine sports workflows

Operating dynamic systems like this requires a different mindset. Engineers must be comfortable with abstraction, probabilistic behaviour and indirect control. Concepts such as declarative configuration, infrastructure-as-code, rolling updates and continuous deployment are no longer optional implementation details. They are core operational tools.

Many media engineering teams are highly skilled, but their experience is often rooted in environments where behaviour is engineered upfront and then protected. That experience does not automatically translate to running distributed software platforms. This is not a criticism of legacy skills. It is a recognition that the problem space has changed.

Kubernetes as an operational forcing function

This gap becomes particularly visible when media platforms are deployed on Kubernetes or its managed equivalents. Kubernetes is frequently described as plumbing, something abstracted away by cloud providers. In practice, it acts as an operational forcing function.

Even when the control plane is managed, engineering teams remain responsible for how workloads are designed, packaged and scheduled. They must decide how services scale, how resources are requested and constrained, how networks are segmented, how security boundaries are enforced, and how costs are controlled. They must also manage upgrades, failure recovery and capacity planning in environments where nothing is truly static.

Kubernetes does not eliminate complexity. It redistributes it away from physical infrastructure and into software design and operational discipline. Teams that lack confidence in these areas often experience the platform as fragile or unpredictable, even when the underlying architecture is sound.

Observability as a cultural shift

The most profound shift introduced by cloud-native systems is not containerisation itself, but observability. Traditional broadcast monitoring focuses on known failure conditions and explicit alarms. Cloud-native systems fail in more subtle ways. Degradation is often partial, transient or emergent, and there may be no single component that is clearly broken.

Effective operation depends on understanding system behaviour through aggregated metrics, structured logs and distributed traces, often built around tooling approaches exemplified by systems such as Prometheus. More importantly, it requires a shift from device health to service-level thinking, where objectives are defined in terms of outcomes rather than component status.

This is a cultural change as much as a technical one. Engineers move from reacting to alarms to continuously interpreting behaviour, making informed trade-offs between performance, resilience and cost. Without this capability, cloud-native media platforms quickly become opaque and difficult to trust.

The danger of platform-level lock-in

One of the stated goals of initiatives like DMF, TAMS and LPX is to reduce vendor lock-in through open interfaces and interoperability. Paradoxically, insufficient operational capability can undermine that goal.

Read more DMF and MXL in practice: Which vendors are adopting it, and how fast is the ecosystem maturing?

When organisations lack confidence in running container platforms themselves, responsibility drifts back towards vendors and managed offerings. Over time, these platforms can become opaque black boxes that are difficult to modify or exit. The result is not freedom, but a new form of lock-in, shifted from hardware to platforms and services.

This is not a failure of standards or architecture. It is a failure to invest in the skills needed to exercise choice.

Why leadership matters

It is tempting to frame this challenge as a training issue for engineering teams. In reality, it is a leadership problem. Developing cloud-native operational capability requires time, tolerance for learning through failure, and a willingness to accept new models of risk. It also demands investment in tooling, observability and platform ownership that does not always deliver immediate, visible features.

Most importantly, it requires a shift away from project-based thinking. DMF-style facilities are living systems. Reliability and efficiency emerge through continuous operation and iteration, not through one-off design approval. That mindset must be supported and reinforced from the top.

Turning architectural intent into operational reality

The Dynamic Media Facility is a powerful signal that the industry understands where it needs to go. It articulates a future in which media facilities are interoperable, software-defined and cloud-native by design.

But architecture alone is not enough. Without sustained investment in operational capability, particularly around container platforms, observability and modern software operations, the promise of DMF and related initiatives will only be partially realised.

The media industry does not have a technology problem. It has a capability gap. Understanding how to close this capability gap, and what it means for engineering teams and leadership alike, is now one of the central questions facing the industry as cloud-native media moves from theory to normal operation.

Sharing

Related Articles

BEFORE YOU GO...

You could get sports broadcasting & production articles like this sent directly to your email inbox.

Simply sign up for one of our 'Insider' newsletters:

IMPORTANT: Once subscribed, PLEASE ADD our email address [email protected] to your safe sender list to ensure safe delivery of newsletters

Already have a login? Log in here to manage your newsletter preferences.