Cloud Broadcasting - The Hidden Costs

Unless you are a greenfield site, have one vendor to meet all your operational and creative needs, or are incredibly lucky, you will at some point need to integrate your Cloud Software-as-a-Service into the broadcast workflows. This is much easier said than done.

Broadcasters have grown accustomed to bespoke systems that are built and fine-tuned to meet their needs. SDI has given us guaranteed network speed, latency and reliability. Routing matrices empower us to connect equipment in ways manufacturers could never have dreamed of, and even the humble GPI is known for making disparate systems work harmoniously together.

Hardware control systems have standardized on a few serial and ethernet protocols, allowing systems to be connected and operate together.

No GPI's in the Cloud

Hardware integration in the Cloud is almost impossible. We have no idea where the servers reside, and even if we did they could change without notice as virtualization takes over. Exchanging video, audio and metadata between Cloud services is a challenge, and integrating workflows becomes even more difficult. There are no usable serial ports or GPI’s in the Cloud computing, whether its public or private.

We can integrate into Cloud systems but we come across two big problems; firstly, we must think like Enterprise Software developers, and secondly, we must accept broadcasting is a small fish in a very big pond, and the days when manufacturers would fall over themselves to deliver bespoke systems are gone.

The only means of connection we have to a Cloud Datacenter is through the internet

Your CEO will have by now been sold all the hype about SaaS services; how perfect they are, pay-as-you-go cost models, and systems with near 100% reliability. The harsh reality is to deliver SaaS systems at the price and reliability offered something must give, and this is mainly two things; support and customization.

Web-App Skillsets

There are SaaS companies out there that will provide customization services for you, but you must think like an IT developer to truly leverage their functionality and power. The reason for this is very simple; Universities are teaching software development to students so they can get a job at the end of the course, to get the best chance of a job the student will be taught Web architecture and programming. This is where the money is, whether its online banking or retail.

SaaS services geared towards broadcasting are better than those that are generic SaaS providers. But even these have their limitations as the skillset of most of their developers will be in the web-app domain, and the ones that can get every clock cycle out of the processor to improve video and audio processing are few and far between. The probability of getting a tweak to a core part of the video or audio processing is quite remote.

Business models for SaaS systems make two important distinctions from traditional hardware manufacturers; they want one configurable version of the software, and they offer “flow diagram” support. That is, the person offering the support will follow a list of questions to try and ascertain the problem, if they can’t help you then the query is passed on further up the chain. And the further you are passed up the chain, the longer the time the service level agreement allows for the problem to be resolved. If you use Amazon Web Services as your host, you’re competing with BMW or the US Department of State. SaaS providers will support you, but it’s not going to be to a level we’ve come to expect from hardware vendors in the broadcast arena.

Code Must be Maintainable

For this reason, some SaaS providers hook up with broadcast specialists who both understand their software, can convert between IT and Broadcast speak, and save many hours of learning time for the new broadcaster.

In the past, software in broadcast systems has taken on a complexity of its own as different versions are created to meet the customized requirements of individual broadcasters. The software soon becomes a nightmare to maintain as a new function for one customer may not find its way into the code of another customer. The knock-on effect is support and software upgrades become extremely difficult and testing all the different versions for different clients becomes almost impossible.

Code written for many different clients and use cases can quickly become difficult to maintain and support.

Code written for many different clients and use cases can quickly become difficult to maintain and support.

A solution is to build one software version which is configurable for all clients, so there is only one version of code to develop, test and support. A back-end database holds configuration information tied to specific user accounts, which is modified when different options are purchased and is completely automated.

Reliability and Reduced Costs

The downside is it lacks the kind of flexibility broadcasters have come to expect from vendors over the past fifty years. New feature requests can be submitted but they are put into a queue called the “backlog” in Agile terms, and then prioritized by the Product Director (PD) and Development Manager. The PD must decide which features will be developed next, this is usually related to increasing sales and supporting key clients.

The upside is improved reliability and significantly lower costs. Automated testing can be better implemented as the different combinations of features and users is easily accessible from the database, resulting in better defined test vectors and results.

Work with the New Technology

SaaS is new to broadcasting and will help many entrepreneurs achieve remarkable success due to its low entry to market costs, feature rich functions and ease of use. But it does have its limitations and we must understand these before we sign-up to a service. The cost per month pales into insignificance compared to the number of man-hours needed to understand how a service works. Time investment of technology teams is a hidden cost, but it’s one that must be factored into a project, along with support, before a new SaaS service is subscribed too.

Broadcasters must realign their expectations when using SaaS products. They are empowering entrepreneurs and broadcasters to deliver systems with incredibly short lead times and reduced cost, but this speed and lower cost comes at a price. If broadcast engineers accept and work with this new philosophy they will achieve remarkable success throughout their career.

You might also like...

KVM & Multiviewer Systems At NAB 2024

We take a look at what to expect in the world of KVM & Multiviewer systems at the 2024 NAB Show. Expect plenty of innovation in KVM over IP and systems that facilitate remote production, distributed teams and cloud integration.

NAB Show 2024 BEIT Sessions Part 2: New Broadcast Technologies

The most tightly focused and fresh technical information for TV engineers at the NAB Show will be analyzed, discussed, and explained during the four days of BEIT sessions. It’s the best opportunity on Earth to learn from and question i…

Standards: Part 6 - About The ISO 14496 – MPEG-4 Standard

This article describes the various parts of the MPEG-4 standard and discusses how it is much more than a video codec. MPEG-4 describes a sophisticated interactive multimedia platform for deployment on digital TV and the Internet.

The Big Guide To OTT: Part 9 - Quality Of Experience (QoE)

Part 9 of The Big Guide To OTT features a pair of in-depth articles which discuss how a data driven understanding of the consumer experience is vital and how poor quality streaming loses viewers.

Chris Brown Discusses The Themes Of The 2024 NAB Show

The Broadcast Bridge sat down with Chris Brown, executive vice president and managing director, NAB Global Connections and Events to discuss this year’s gathering April 13-17 (show floor open April 14-17) and how the industry looks to the show e…