Why, how and what you need to build for the web.
The web is not new.
It’s old enough now to have written its own history, and rewritten the rules of software development in the process. And yet, when it comes to building systems in the media and entertainment industry, we still treat it like an afterthought. Like a “target platform.” As if we can simply deploy something “to the web” and expect it to behave.
We can’t.
The web is not a delivery channel. It's an architecture. It’s a way of building.
And if we want to make use of what the web really offers, if we want to unlock the scalability, the elasticity, the global reach, the inherent security models, we need to build for it. Not just push things onto it.
Let’s start there.
Scalability is Not Just a Promise. It’s a Contract.
One of the web’s superpowers is its ability to scale without ceremony. In the hyperscale world, there’s no applause when your service handles a hundred million requests. That’s the job.
But scalability is not magic. It comes from stateless design. From asynchronous patterns. From services that are horizontally decomposed, distributed, and deployed in containers, orchestrated by platforms like Kubernetes or serverless frameworks.
If your application needs to know where it’s running or how many copies of itself there are, it's not web-native. If it keeps state in memory instead of in a distributed cache, it won't scale.
Security Is Intrinsic. Not Optional.
In media, we often treat security as something that gets wrapped around our products. A firewall. A VPN. A sternly worded legal contract.
But in the web world, zero trust is the baseline. Services don’t assume they’re safe just because they’re inside a perimeter, because there is no perimeter. Every service authenticates, every request is encrypted, and every decision is verified.
This is not just about compliance. It’s about building systems that can safely connect across boundaries, across networks, clouds, and companies, without compromising control.
Security is not something we “add later.” It’s something we build into the architecture.
Elasticity: Pay for What You Use. Get What You Need.
The web doesn’t just scale, it flexes. It’s elastic.
Spin up a transcoder when a job arrives. Spin it down when it's done. Serve previews on demand. Route requests to the nearest edge. That elasticity changes the economics of media technology. We don’t have to pre-provision. We don’t have to overbuild. We just have to build it right.
But to do that, we have to unlearn decades of infrastructure thinking. The web is not a box. It's a fabric. We don’t ship software to a machine anymore. We ship it to the mesh.
So How Do We Build for the Web?
Here’s a rule of thumb: if it worked well in a monolithic broadcast appliance, it probably won’t survive contact with the web.
To build for the web, we need to think in:
- Lego bricks, not monoliths – small, composable, testable units that can be independently deployed, replaced, and scaled.
- Events, not procedures – asynchronous messaging that allows for real-world delays, retries, and recoveries.
- Containers, not servers – environments that can be spun up and torn down in seconds, with no human intervention.
- Interfaces, not dependencies – clear, documented APIs that describe behaviour, not implementation.
- State, stored deliberately – in databases and caches that are themselves scalable and shared, not in memory or session.
- Observability, not guesswork – logs, metrics, traces, and telemetry that let us see, diagnose, and improve in real time.
And, most importantly, we build for failure.
This Isn’t a Philosophy. It’s a Pragmatic Advantage.
I’m not evangelising because I like the sound of it. I’m saying this because we’re already seeing the cost of doing it the other way.
Systems that were “adapted” for the web are failing under load. Security holes are being patched one exploit at a time. Customers expect SaaS and get screen-sharing instead. Broadcasters want “cloud” and get “a virtual machine in the basement”.
Meanwhile, the companies who built for the web from the beginning are moving faster, shipping sooner, scaling effortlessly, and iterating with confidence.
Building The AirFrame Server. How Did We Do It?
Below, you’ll see a diagram I have shared recently with industry peers based on the EBU’s work on the architecture of Dynamic Media Facilities. Turns out, they describe how we’ve built AirFrame. This is a zoomed out summary of how AirFrame maps onto the Stack that represents a modern media system.
This is the big picture. The layers or ‘stack’ of a modern media system that’s built to operate on the web, not just exist on it.
Let’s walk it from the ground up:
- Infrastructure: Whether it’s on-prem, hybrid, or fully cloud-native, everything can run in Kubernetes. That gives us scheduling, orchestration, and the basis for horizontal scalability.
- Platform: The web is hyperscale now. Load balancers (ALB), auto-scaling groups (ASG), and DNS give us global distribution and resilience out of the box. We’re not reinventing this, we’re using the best of it.
- Runtime: Containers. Always. Serverside, we package everything in Docker and can deploy into K8s environments. That gives us portability, repeatability, and zero-downtime updates.
- Security and Provisioning: Zero-trust principles, OAuth, OKTA, TLS, are built in from the start. Not added later. And everything is provisioned as code (Terraform), so it can be rebuilt, tested, and rolled back at will.
- Monitoring and Control: Observability is not optional. We use OpenTelemetry for logs and traces. And we treat timelines (OTIO - OpenTimelineIO), control inputs and playlists as first-class citizens. They drive behaviour.
- Media Layers: This is where it gets interesting. An asynchronous media API gives us the backbone of media exchange, with no stateful connections, no blocking calls. Just messages, events, and outcomes. On top of that, the AirFrame Mesh, a distributed network of nodes, functions capable of reading, writing, and transforming media at scale.
- Applications: Premiere. A browser. A camera. Whatever the client is, it talks to the stack through clean, documented APIs. No plugin voodoo, no assumptions about the environment.
Each layer does what it does best. Each layer is replaceable. That’s the web way.
The AirFrame Server: Built With a Purpose
Internally we call the core of our server “Fuselage” because it holds everything together. It’s not a monolith. It’s a modular, media-native, API-first architecture for tier 1 live, near-live and archive workflows.
It speaks HTTP. It runs in the cloud. It reflects the best practices of modern web technology, and is designed with our deep experience of the requirements of media workflows - which all start with a single frame.
If you’re leading a team, ask yourself: are we building for the workflows we know, or the ones the supply chain and audiences are demanding? And what becomes possible when you build for the web?
Dr. Richard Cartwright, Technical Lead, Media-Anywhere. richard@media-anywhere.com
