Getting More From Your Technology Stack

There is a point at which making an individual task easier stops delivering meaningful operational efficiency. Removing a few steps from a configuration process is useful, but if an engineer still needs to repeat that process across every event, service or workflow, the underlying workload remains.

This becomes particularly noticeable as live IP operations scale. Processes that are perfectly manageable for a handful of occasional feeds can create significant overhead when repeated across multiple events, destinations, customers and regions. The individual tasks may not be particularly difficult, but collectively they consume time and create more opportunities for something to be missed.

For us, this is increasingly where orchestration needs to do more than simply provide a convenient way to control different technologies. The platform itself needs to take responsibility for more of the operational work surrounding a live service.

 

Treating the workflow as the unit

Earlier this year we introduced the term atomic orchestration to describe the way Livelink treats all of the resources associated with a workflow as part of a single operational entity.

A live workflow involves considerably more than a video path. Infrastructure may need to be provisioned, transport established, processing applied, monitoring configured, security rules created and operational data recorded. All of those things are necessary, but there is no reason an operator should always have to coordinate them individually.

With atomic orchestration, those supporting services are created as part of the workflow itself and follow its lifecycle. Monitoring, logging, alerting, billing and security are not separate activities that need to be remembered before an event starts or cleaned up after it finishes. They exist because the workflow exists and are removed with it when they are no longer required.

The immediate benefit is a simpler operational process, but there is a wider consequence too. The knowledge required to deploy a service consistently begins to sit within the workflow rather than relying entirely on the individual engineer operating it.

 

Where engineering expertise adds value

Experienced broadcast engineers are one of the industry’s most valuable resources. Their ability to design resilient services, diagnose problems and make decisions under the pressure of live operations is difficult to replace. It therefore makes little sense to consume more of that expertise than necessary on repetitive provisioning, configuration and housekeeping.

That does not mean removing engineers from the process or hiding the technology from them. There will always be circumstances in which somebody needs to get into the detail. The opportunity is to make sure that expertise is being applied where it actually contributes to the quality and resilience of the service, rather than using people as the integration layer between systems.

This philosophy has shaped Livelink for some time, but it is becoming more significant as the platform develops. We are looking not only at how workflows are created and stopped, but at how they can be reused, how resources are managed throughout their lifecycle, how operational information is surfaced and where the platform can act on decisions that have already been made.

 

Building on the operational layer

Earlier this year, Livelink received the IAMT Best Operations & Lifecycle Award. The recognition itself was obviously welcome, but what was particularly relevant was the judges’ focus on orchestration, self-service, multi-protocol support and the scalability of the platform.

Those observations reflected an area of Livelink that we have continued to invest in: the operational layer surrounding the video workflow. Moving content reliably remains fundamental, but there is a much broader set of activities required to make that service practical to operate day to day.

The next stage of Livelink’s development continues in that direction. The capabilities we are introducing around IBC are not intended to change the underlying philosophy of the platform, but to extend it. We want more of the repetitive operational work around a live service to be handled consistently by Livelink, while giving the people responsible for that service better information and more appropriate ways to interact with it.

As live workflows become more distributed and incorporate more technologies, there will inevitably be more happening underneath them. That does not have to mean a corresponding increase in the work required to operate them.

For us, that is where orchestration becomes particularly valuable: not simply connecting the individual parts of a workflow, but making the complete service easier to run.