Cloud Broadcasting - The Business Case for Cloud Computing

In the previous Cloud Broadcasting article, we looked at the differences between public and private clouds. In this article, we delve further into Cloud Born systems and define the business case for cloud computing.

There are three major cost savings associated with cloud systems; reduction of over-specified systems, resource on demand to meet peak requirements, and consolidation of IT and network teams. If a broadcaster no longer has a datacenter, they don’t need a team of industry professionals to maintain and support it 24/7.

No Crystal Ball

Datacenters tend to be over-specified as there is a key business need to build resilience into the system, and allow for future expansion. The resilience is easy to calculate and plan for, however, it is based on the future growth projections of a broadcaster or service provider. How many new servers will a broadcaster need in two years? How much storage will they require going forward?

Sales directors do not have a crystal ball, and as much as we would like to blame them for not predicting business trends thus allowing us to know exactly how much resource to procure, this is not a rational position to take. The bottom line is nobody knows for certain how any business will be performing in a year, two years, five years or ten years. To deal with this unpredictability we add a tolerance, and in practical terms the IT Director will over-spec the datacenter to take into consideration their perception of future growth. It’s a finger in the air estimate based on the broadcasters’ previous history and the experience of the IT Director.

Highly Efficient Production Lines

The whole budgeting process is geared to over estimation as the annual event leaves little flexibility. A vicious loop ensues as the IT Director over estimates resource to take into consideration their perception of increased sales, and the CEO increases the Sales Directors targets to pay for the increased overheads of the IT resource. To support all this extra overhead, we must employ more IT engineers, and then we need more office support from HR, finance and facilities managers for the bigger building we will need to move into to accommodate all the new staff.

This is how heavy industry businesses of the past used to work. A production line would start with a massive capital investment to build a model of car. The costs would be spread over many cars and years driving down the unit cost per vehicle.

Diagram showing the vicious circle of over-specification of IT datacenters based on the perception of increased sales

Diagram showing the vicious circle of over-specification of IT datacenters based on the perception of increased sales

The capital investment model of the past doesn’t work for IT based industries, for one very simple reason; products and services change with incredible speed. SaaS businesses change their websites weekly, and sometimes even daily in a bid to attract a greater market share and increase sales.

On-Demand Resource

As broadcast moves away from the artisan provider of the past to a slick production line model where procurement departments are the norm and standard operating procedures prevail, we need to change the sluggish capital investment model of the past to a fast, light and responsive model to gain larger market share of viewers. Preferably one with low fixed overheads and operating costs directly proportional to sales.

And cloud providers do exactly that. They spread the heavy capital investment costs across many different clients, from lots of different industries, to reduce the fixed unit cost to a low level, and in a stroke of genius deliver a service where the resource available can expand and contract at the touch of a button.

Public or Private Cloud?

Imagine a playout service which can start with broadcasting to one viewer at a cost of $10, but then scale to ten million viewers in a matter of minutes at a cost of $1M. Yes, it costs $1M, but only during the peak demand and when this diminishes so do the operating overheads. Using this model CEO’s and business owners can easily predict and test the viability of a business idea. It will probably mean new ways of monetizing content must be found. But the market will be wide open to new entrepreneurs whose success is only limited by their creativity.

Two versions of the cloud are available; public and private. Proponents of private cloud will tell you they are far superior as you have all the advantages of the public cloud; resilience, virtualization and scalability, with the addition of more control to tweak the system to “broadcast” needs.

The private cloud is essentially a datacenter owned by the broadcaster with their own IT team managing the required services. It is resilient, it has virtualization, but to suggest it’s scalable is stretching the truth a bit. It’s scalable within the limits of the hardware available, which has probably been over specified to take into consideration the perceived increase in sales which results in high capital investment.

Broadcasters of the future will keep their entire signal chain in the public cloud.

Public clouds are truly scalable, no matter how many virtual servers you require, there are always more available on a pay-as-you-go contract. If you run out of resource, then spin up another server. The winners of broadcast SaaS service providers will be those providers who have written Cloud Born software that can scale horizontally across multiple servers, in effect they have been programmed as parallel systems.

Although functional programming (parallel programming) has been available as a concept for many years, it has only recently started to move into mainstream coding. And when a vendor tells you their software can work in the cloud, that doesn’t mean it is scalable to the point where it leverages cloud savings. The question to ask is “which functional code do your developers use?”.

Private Generators are Obsolete

In a private cloud, whether it’s situated at the broadcaster or not, the IT and networks teams are responsible for maintaining and servicing the hardware and delivering a service to the business. In a public cloud, a third party provides the systems which take the place of the major functions provided by the IT and network teams, developers and dev-ops teams are responsible for configuring and supporting the service.

A good analogy is to compare broadcast stations with the weaving mills of the late nineteenth century. Each of these mills had their own power source such as a water wheel or steam engine because a reliable distributed power network was unavailable. And then the national grid was invented. At first businesses were slow to adopt the new power service because they considered it insecure or unreliable. Now spin forward one hundred years and there are few businesses who use their own power plant.

Broadcasters Must Use Public Cloud

This is exactly what is happening to the broadcast industry now and its adoption of public clouds. The broadcaster of the future will consist of operational control panels connected to the cloud, where all the audio and video processing takes place. The only time the program comes back to earth is for broadcast monitoring feeds, or the program delivered directly to the viewer.

Modern consumer trends demand fast technological change, for broadcasters to meet this expectation they must use public clouds.

You might also like...

Designing IP Broadcast Systems - The Book

Designing IP Broadcast Systems is another massive body of research driven work - with over 27,000 words in 18 articles, in a free 84 page eBook. It provides extensive insight into the technology and engineering methodology required to create practical IP based broadcast…

Demands On Production With HDR & WCG

The adoption of HDR requires adjustments in workflow that place different requirements on both people and technology, especially when multiple formats are required simultaneously.

If It Ain’t Broke Still Fix It: Part 2 - Security

The old broadcasting adage: ‘if it ain’t broke don’t fix it’ is no longer relevant and potentially highly dangerous, especially when we consider the security implications of not updating software and operating systems.

Standards: Part 21 - The MPEG, AES & Other Containers

Here we discuss how raw essence data needs to be serialized so it can be stored in media container files. We also describe the various media container file formats and their evolution.

NDI For Broadcast: Part 3 – Bridging The Gap

This third and for now, final part of our mini-series exploring NDI and its place in broadcast infrastructure moves on to a trio of tools released with NDI 5.0 which are all aimed at facilitating remote and collaborative workflows; NDI Audio,…