When you talk to Tony Jones about cloud-native, microservices and Kubernetes, it’s easy to forget that he’s been at the leading-edge of video tech transformation since 1996, when he first joined Tandberg Television. I should know, since I joined Tandberg TV just after Ericsson acquired it and spent the next five years privileged to learn deep video tech from Tony and others.

Today, that company, with a few sharp acquisitions along the way, is MediaKind. And Tony Jones is a Principal Technologist, looking after product strategy across the portfolio. 

After catching up, Tony painted the big picture, which was helpful in understanding how and why the company has embraced SRT.

“More than a few years ago, we made a fundamental decision to move toward cloud technology wherever possible. So that’s been an important theme that we’ve run through our entire portfolio. The other one, which works alongside that – it’s banged up with it, but it’s not one-and-the-same thing – is moving toward microservices architectures. So we’re trying to compose products, typically using Kubernetes, out of pods that have multiple containers in them.”

For non-technical readers, a pod is typically used to describe a unit of application deployment in a Kubernetes node. (A node is analogous to a server in legacy environments.) Multiple such deployments can be managed as a single cluster, even if the services are actually distributed globally.

The idea of having multiple containers in each pod is that you gain tremendous flexibility and agility in spinning up new workflows. For example, one container might enable encoding, another might providing decoding, and yet another might be suited to transmit SRT.

Tony continued:

“Importantly, containers inside a pod communicate directly using localhost, so there’s no need to discover the location. So now you’ve got an SRT transmit block for example, or an SRT receive block, we can then take that and apply it to anything that’s a containerized microservices-based product. And we’ve done that. We’ve built SRT pods that do the transport and receive, and have shown that we can create both encoders and decoders, dynamically, for contribution links.”

Essentially, instead of a series of fixed-function encoders and decoders located around the world, what Tony described is a network of servers, all of them formed into a single Kubernetes cluster which can be used in a variety of ways in a highly elastic and flexible operation.

“The trick left is to coordinate the interconnections between them, and the lifecycle of them, and there you go, you’ve got the ability to build connections on-demand.”

Tony really crystallized the big picture for me – or maybe that’s the deep-dive picture? – and so I wanted to get a bit more practical about the “growth use cases” he saw coming. What would drive these workflows from the labs into the real world?

One commonly talked about growth case involves the distribution of national broadcast feeds, think CBS or NBC, for example to each of the main broadcast affiliates that carry those feeds. There are 210 designated TV markets in the US, and today that distribution is done primarily via satellite using fixed infrastructure. It works, but it’s easy to see why programmers are eager to migrate toward more flexible, IP-based infrastructures.

“Take the example of broadcast blackouts, where a local station has to find something else to air in the place of a local baseball game. Today, the switching between the typical time zone feed and the blackout alternative is done by a rack of receivers at the local affiliate, with some custom software on a custom box. With this ability to establish a more flexible, connected network, you can easily imagine that being a more centralized function. It would be done on behalf of the local region, but, you can imagine the ability to regionalize content or generate targeted ads, where that is happening centrally but on behalf of the local site. That’s the kind of thing where these various flavors of UDP over IP can play a key role.”

I asked Tony to weigh-in on the choice to use SRT vs. other protocols.

“We don’t have a philosophical objection to any of them. Except for the fact that we are reluctant to get tied into proprietary schemes unnecessarily. So the open sourcing of SRT made it a good candidate for adoption by the whole industry without any one organization having an undue influence or a mandatory presence in the middle of the system.”

To learn more from Tony, and to learn how cloud technology – along with SRT – can be used to more efficiently and flexibly distribute network programming to broadcast affiliates,  be sure to visit the MediaKind stand at 4.A01 at IBC.

If you’re interested in finding out more about SRT at IBC, sign up for this free to attend  SRT Open Source Technical panel on September 15th. Designed for current and future SRT developers, the panel will focus on the applications and workflows that SRT solves, the technical roadmap, as well as implementation stories.